From simple-bounces@ietf.org Sat Jul 02 00:33:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoZgv-0000OZ-L7; Sat, 02 Jul 2005 00:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoZgp-0000OP-NF for simple@megatron.ietf.org; Sat, 02 Jul 2005 00:33:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08011 for ; Sat, 2 Jul 2005 00:33:12 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Doa6u-0004pk-Dm for simple@ietf.org; Sat, 02 Jul 2005 01:00:13 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2005 21:33:04 -0700 X-IronPort-AV: i="3.93,252,1115017200"; d="scan'208"; a="285217347:sNHT29028920" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j624WxvM001632; Fri, 1 Jul 2005 21:32:59 -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); Sat, 2 Jul 2005 00:33:03 -0400 Received: from [192.168.1.100] ([10.86.243.56]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 2 Jul 2005 00:33:02 -0400 Message-ID: <42C618FD.7010006@cisco.com> Date: Sat, 02 Jul 2005 00:33:01 -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: Henning Schulzrinne Subject: Re: [Simple] element issue for common policy References: <42BC7CB6.7070503@cs.columbia.edu> In-Reply-To: <42BC7CB6.7070503@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2005 04:33:03.0040 (UTC) FILETIME=[225E8400:01C57EBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: Ted Hardie , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org add mine to the list of apologies for long delays in responses.. more inline. Henning Schulzrinne wrote: > Ted Hardie wrote: > >> I agree that having the clause for applicability within the >> rule is better than the cases GeoPriv was most concerned with (it's >> always processed at the same time, so the evaluation order problem >> isn't salient). It is, though, a negative permission--it's a grant >> to all followed by a revoke to a limited set. One of the issues I >> expressed is that the limited set isn't useful, because of identity >> minting. The other is that the except clause here forces a change to >> the processing model. I'm concerned that changing the processing >> model to (Grant, followed by revoke) will open us to things that will >> have the problems GeoPriv wanted to avoid. > > > I don't quite agree with the statement of the model made above. This is > not "grant, then revoke". Rather, the exception condition restricts the > matching of the rule. Logically speaking, rule processing proceeds in > two phases: > > (1) Determine if the rule matches a request (subscription, location > request, etc.) > > (2) Execute the actions and grant the permissions (it's a bit more > complicated, but irrelevant for this discussion). > > The "all except" part only affects the matching (step 1), not the action > (step 2). > > This is an important difference, as it avoids the privacy unsafety > issues that grant-then-revoke would have. Rules are binary in matching, > i.e., they either match or don't, and thus the consequences you seem to > fear cannot occur, inside or outside of the geopriv context. > > I want to make the difference clear since I was also confused on this > point when this whole discussion started a year or so ago. > > Thus, to make up another example that avoids the identity-minting issue, > "Apply this rule at any location except New York" would be perfectly fine. > > The distinction becomes clearer if you consider hypothetically that we > might allow regular expressions in the matching part. We could have > something like > > [^0-9] > > which can be phrases as "any character except 0-9". Or, if we had a > numeric matching condition, something like "x > 9 || x < 0" could just > as easily be phrased as "any x except between 0 and 9". Clearly, neither > of these examples are "grant/revoke" conditions. Right. Put another way, putting an exception in the matching condition is just another way to define the set of users to whom the additive permissions apply. The only difference is that the set of people to whom they apply is potentially large, but there is no change in the model. Ted previously wrote: > Except clauses that are clearly tied to specific directives are better > than all-out negative permissions, but they can remain problematic > in their interaction with user expectations. If I say "Grant anyone > access to my timezone, except Hisham" and also say "Grant any > wg chair in APPs access to my full location", Hisham will get my > time zone--but this may not be what a user expects, especially > if the user expectation is driven by a sense of "override" and > wrote the "except Hisham" after the first rule was in place. This concern is valid under the assumption that users directly manipulate these rules. I dont think that this is going to be the case. I think that web applications and other things will provide nice UI for these, and present the user with decisions they can understand. An application might ask the user to define the set of watchers that are to be blocked. Separately, the user might provide lists of people to whom various information is to be granted. I think the web application would automatically add the blocked users to the exception list for every rule. This preserves the expected user experience. I've been on the fence on this topic for a long time, but at this point I am pretty solidly in favor of supporting exceptions for users within a domain rule, and exceptions for domains within an any rule. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Sun Jul 03 23:25:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpHaT-0002Lg-RM; Sun, 03 Jul 2005 23:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpHaS-0002Lb-2t for simple@megatron.ietf.org; Sun, 03 Jul 2005 23:25:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12563 for ; Sun, 3 Jul 2005 23:25:33 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpI0w-0007cW-3O for simple@ietf.org; Sun, 03 Jul 2005 23:52:59 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 03 Jul 2005 20:25:25 -0700 X-IronPort-AV: i="3.93,254,1115017200"; d="scan'208"; a="196187013:sNHT25560084" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j643P8Vl008179; Sun, 3 Jul 2005 20:25:24 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Jul 2005 20:29:41 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 03 Jul 2005 19:53:46 -0400 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension From: Cullen Jennings To: Orit Levin , "simple@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Jul 2005 03:29:42.0127 (UTC) FILETIME=[9DACB7F0:01C58048] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On 6/30/05 9:23 AM, "Orit Levin" wrote: > We don't have to have both if we agree that we use Digest as the common > denominator for all purposes (including for issuing the token) instead > of Basic. Yes, I understand now - that makes sense. I feel strongly that Digest is better idea than both but don't have as strong as feeling between Basic+TLS and Digest. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 04 00:59:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpJ2u-000808-DW; Mon, 04 Jul 2005 00:59:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpJ2s-000803-26 for simple@megatron.ietf.org; Mon, 04 Jul 2005 00:59:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19317 for ; Mon, 4 Jul 2005 00:58:59 -0400 (EDT) Received: from ylpvm12-ext.prodigy.net ([207.115.57.43] helo=ylpvm12.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpJTM-0005ER-U5 for simple@ietf.org; Mon, 04 Jul 2005 01:26:26 -0400 Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j644wvpJ011119 for ; Mon, 4 Jul 2005 00:58:57 -0400 X-ORBL: [70.249.148.178] Received: from [192.168.0.101] (ppp-70-249-148-178.dsl.rcsntx.swbell.net [70.249.148.178]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j644wwFu291518; Mon, 4 Jul 2005 00:58:58 -0400 Message-ID: <42C8C215.7020103@nostrum.com> Date: Sun, 03 Jul 2005 23:59:01 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: Orit Levin , "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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Cullen Jennings wrote: >On 6/30/05 9:23 AM, "Orit Levin" wrote: > > > >>We don't have to have both if we agree that we use Digest as the common >>denominator for all purposes (including for issuing the token) instead >>of Basic. >> >> > >Yes, I understand now - that makes sense. I feel strongly that Digest is >better idea than both but don't have as strong as feeling between Basic+TLS >and Digest. > I'm probably rehashing old arguments here, but I do have a reasonably strong feeling about this. If I want to go through my "home" relay for message logging purposes, but first need to go through a firewall-traversal relay at a client's site, I'd prefer to have the ability to do so without giving the client's relay an opportunity to intercept my "home" relay password. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 11:58:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppoU-0003la-T4; Tue, 05 Jul 2005 11:58:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppoT-0003l2-Px for simple@megatron.ietf.org; Tue, 05 Jul 2005 11:58:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14226 for ; Tue, 5 Jul 2005 11:58:17 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpqFD-0003Mo-6s for simple@ietf.org; Tue, 05 Jul 2005 12:26:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j65FgbNC003794; Tue, 5 Jul 2005 18:46:01 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 18:50:10 +0300 Received: from [192.168.1.185] ([10.162.252.207]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Jul 2005 18:50:11 +0300 Message-ID: <42CAAC30.6080005@nokia.com> Date: Tue, 05 Jul 2005 18:50:08 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Orit Levin Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2005 15:50:11.0571 (UTC) FILETIME=[3A199C30:01C58179] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Inline. ext Orit Levin wrote: > We don't have to have both if we agree that we use Digest as the common > denominator for all purposes (including for issuing the token) instead > of Basic. > > That being said, I agree that for issuing the MSRP forwarding tokens - > Basic syntax is enough. You could invent any other simple way of > exchanging a password forth and a token back - this is not exactly what > authentication is. Sorry, but what? That is exactly what authentication is; I present valid credentials to access a resource that in this case is the MSRP forwarding token. > The draft must clarify WHAT the described Basic format is being used for > (i.e. for issuing the MSRP forwarding token only) instead of saying that > this is THE way for a Relay to authenticate a client. Are you saying that the draft should describe Basic as something else and not authentication? If that is the case, I don't agree with it. > Also the spec must say that in order for a Relay to securely > (confidentially) authenticate a client, additional authentication > mechanisms MAY be defined to be used with MSRP. The spec must specify > NOW how the "issuing a token Basic-based procedure" will coexist with > any other real authentication procedures that (most probably) will ALSO > use the HTTP methods and formats. (It is really about "co-existence" > rather than "negotiation".) You seem to suggest that MSRP needs a challenge-response scheme because there is some other authentication scheme you intend to use with it. You wouldn't be talking about NTLM authentication here now would you? Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 13:04:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqqN-0003XG-K1; Tue, 05 Jul 2005 13:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqqL-0003VN-FO for simple@megatron.ietf.org; Tue, 05 Jul 2005 13:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23996 for ; Tue, 5 Jul 2005 13:04:15 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DprH4-0000Zq-63 for simple@ietf.org; Tue, 05 Jul 2005 13:32:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2005 10:04:06 -0700 X-IronPort-AV: i="3.93,261,1115017200"; d="scan'208"; a="196410793:sNHT26821616" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j65H41od018296; Tue, 5 Jul 2005 10:04:01 -0700 (PDT) Received: from [10.0.1.3] ([10.21.145.120]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 10:08:26 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 05 Jul 2005 13:04:01 -0400 Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension From: Cullen Jennings To: Adam Roach , Orit Levin , "simple@ietf.org" , Rohan Mahy Message-ID: In-Reply-To: <42C8C215.7020103@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Jul 2005 17:08:26.0271 (UTC) FILETIME=[285BFAF0:01C58184] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On 7/4/05 12:59 AM, "Adam Roach" wrote: > I'm probably rehashing old arguments here, but I do have a reasonably > strong feeling about this. If I want to go through my "home" relay for > message logging purposes, but first need to go through a > firewall-traversal relay at a client's site, I'd prefer to have the > ability to do so without giving the client's relay an opportunity to > intercept my "home" relay password. If we agree that the above use case is a valid use case, then I imagine this discussion is probably over and all will agree we need to move to Digest. Rohan had some sort of argument that amounted to "Don't do this". Can we decide if we think this is a valid use case or not? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 13:23:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpr5y-00070a-So; Tue, 05 Jul 2005 13:20:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpr5s-0006xe-Te for simple@megatron.ietf.org; Tue, 05 Jul 2005 13:20:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25776 for ; Tue, 5 Jul 2005 13:20:18 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DprPh-0001RR-Sx for simple@ietf.org; Tue, 05 Jul 2005 13:40:55 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j65HD0Fu110356 for ; Tue, 5 Jul 2005 17:13: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.12.10/NCO/VER6.6) with ESMTP id j65HD0vc152352 for ; Tue, 5 Jul 2005 19:13:00 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j65HD0Dc009740 for ; Tue, 5 Jul 2005 19:13:00 +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/8.12.11) with ESMTP id j65HD0a7009732; Tue, 5 Jul 2005 19:13:00 +0200 In-Reply-To: To: Cullen Jennings Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Tue, 5 Jul 2005 20:12:57 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 05/07/2005 20:12:59, Serialize complete at 05/07/2005 20:12:59 X-Spam-Score: 2.3 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Rohan Mahy , Orit Levin , 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="===============1640834447==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1640834447== Content-Type: text/html; charset="US-ASCII"

Cullen Jennings <fluffy@cisco.com> wrote on 05/07/2005 08:04:01 PM:

> On 7/4/05 12:59 AM, "Adam Roach" <adam@nostrum.com> wrote:
>
> > I'm probably rehashing old arguments here, but I do have a reasonably
> > strong feeling about this. If I want to go through my "home" relay for
> > message logging purposes, but first need to go through a
> > firewall-traversal relay at a client's site, I'd prefer to have the
> > ability to do so without giving the client's relay an opportunity to
> > intercept my "home" relay password.
>
> If we agree that the above use case is a valid use case, then I imagine this
> discussion is probably over and all will agree we need to move to Digest.
> Rohan had some sort of argument that amounted to "Don't do this". Can we
> decide if we think this is a valid use case or not?
>
I think that it is a valid use case. The average user will not know that
MSRP is sending the password on the clear over TLS. It will also be very hard
to instruct users to use a gateway in the hotel for example for one protocol and
not for the other. Most users do not even know what protocol their software is
using.

Avshalom
--===============1640834447== 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 --===============1640834447==-- From simple-bounces@ietf.org Tue Jul 05 13:37:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprME-0001YV-8D; Tue, 05 Jul 2005 13:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprM9-0001VK-Pr for simple@megatron.ietf.org; Tue, 05 Jul 2005 13:37:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28427 for ; Tue, 5 Jul 2005 13:37:06 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dprms-0003Xa-AX for simple@ietf.org; Tue, 05 Jul 2005 14:04:51 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j65Hau127138; Tue, 5 Jul 2005 10:36:56 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 10:36:43 -0700 To: Avshalom Houri X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Avshalom, I don't believe that the average user will go and manually configure some MSRP proxy they've never heard of before. What is the use case? Can anyone provide a *good* reason why you should be using arbitrary random relays and why this is reasonable from a security perspective. I personally hope that anyone enlightened enough to have heard of MSRP will be at least enlightened enough to allow outbound TCP connections from their network. thanks, -rohan On Jul 5, 2005, at 10:12, Avshalom Houri wrote: > Cullen Jennings wrote on 05/07/2005 08:04:01 PM: > > > On 7/4/05 12:59 AM, "Adam Roach" wrote: > > > > > I'm probably rehashing old arguments here, but I do have a > reasonably > > > strong feeling about this. If I want to go through my "home" > relay for > > > message logging purposes, but first need to go through a > > > firewall-traversal relay at a client's site, I'd prefer to have > the > > > ability to do so without giving the client's relay an opportunity > to > > > intercept my "home" relay password. > > > > If we agree that the above use case is a valid use case, then I > imagine this > > discussion is probably over and all will agree we need to move to > Digest. > > Rohan had some sort of argument that amounted to "Don't do this". > Can we > > decide if we think this is a valid use case or not? > > > I think that it is a valid use case. The average user will not know > that > MSRP is sending the password on the clear over TLS. It will also be > very hard > to instruct users to use a gateway in the hotel for example for one > protocol and > not for the other. Most users do not even know what protocol their > software is > using. > > Avshalom _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 13:52:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprbE-0003t3-EX; Tue, 05 Jul 2005 13:52:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprbB-0003rf-Ar for simple@megatron.ietf.org; Tue, 05 Jul 2005 13:52:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29946 for ; Tue, 5 Jul 2005 13:52:44 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dprzl-00060c-ME for simple@ietf.org; Tue, 05 Jul 2005 14:18:11 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j65HjEd8008186; Tue, 5 Jul 2005 20:45:25 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 20:50:04 +0300 Received: from [192.168.1.185] ([10.162.252.207]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Jul 2005 20:50:05 +0300 Message-ID: <42CAC84B.3040506@nokia.com> Date: Tue, 05 Jul 2005 20:50:03 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Cullen Jennings Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2005 17:50:05.0248 (UTC) FILETIME=[F9DD9C00:01C58189] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I don't think this is a valid use case. If we are talking about corporate users here (and I assume we are), I have a hard time seeing MSRP logged via anything other than a VPN-tunnel along with other traffic the users generate (such as email). And VPNs seem to pass firewalls quite well already. Cheers, Aki ext Cullen Jennings wrote: > On 7/4/05 12:59 AM, "Adam Roach" wrote: > > >>I'm probably rehashing old arguments here, but I do have a reasonably >>strong feeling about this. If I want to go through my "home" relay for >>message logging purposes, but first need to go through a >>firewall-traversal relay at a client's site, I'd prefer to have the >>ability to do so without giving the client's relay an opportunity to >>intercept my "home" relay password. > > > If we agree that the above use case is a valid use case, then I imagine this > discussion is probably over and all will agree we need to move to Digest. > Rohan had some sort of argument that amounted to "Don't do this". Can we > decide if we think this is a valid use case or not? > > > > > > > _______________________________________________ > 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 Tue Jul 05 13:53:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprbT-000426-FN; Tue, 05 Jul 2005 13:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprbR-00040t-1N for simple@megatron.ietf.org; Tue, 05 Jul 2005 13:53:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00164 for ; Tue, 5 Jul 2005 13:52:59 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dprvf-0005NW-4t for simple@ietf.org; Tue, 05 Jul 2005 14:13:56 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j65Hjj2m005050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2005 10:45:45 -0700 (PDT) Received: from [192.168.1.4] (vpn-10-50-0-32.qualcomm.com [10.50.0.32]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j65HjgRq010288; Tue, 5 Jul 2005 10:45:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42C618FD.7010006@cisco.com> References: <42BC7CB6.7070503@cs.columbia.edu> <42C618FD.7010006@cisco.com> Date: Tue, 5 Jul 2005 10:45:41 -0700 To: Jonathan Rosenberg , Henning Schulzrinne From: Ted Hardie Subject: Re: [Simple] element issue for common policy Content-Type: text/plain; charset="us-ascii" 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org At 12:33 AM -0400 7/2/05, Jonathan Rosenberg wrote: >> >>which can be phrases as "any character except 0-9". Or, if we had a numeric matching condition, something like "x > 9 || x < 0" could just as easily be phrased as "any x except between 0 and 9". Clearly, neither of these examples are "grant/revoke" conditions. > >Right. Put another way, putting an exception in the matching condition is just another way to define the set of users to whom the additive permissions apply. The only difference is that the set of people to whom they apply is potentially large, but there is no change in the model. >Ted previously wrote: >>Except clauses that are clearly tied to specific directives are better >>than all-out negative permissions, but they can remain problematic >>in their interaction with user expectations. If I say "Grant anyone >>access to my timezone, except Hisham" and also say "Grant any >>wg chair in APPs access to my full location", Hisham will get my >>time zone--but this may not be what a user expects, especially >>if the user expectation is driven by a sense of "override" and >>wrote the "except Hisham" after the first rule was in place. > >This concern is valid under the assumption that users directly manipulate these rules. I dont think that this is going to be the case. I think that web applications and other things will provide nice UI for these, and present the user with decisions they can understand. An application might ask the user to define the set of watchers that are to be blocked. Separately, the user might provide lists of people to whom various information is to be granted. I think the web application would automatically add the blocked users to the exception list for every rule. This preserves the expected user experience. > >I've been on the fence on this topic for a long time, but at this point I am pretty solidly in favor of supporting exceptions for users within a domain rule, and exceptions for domains within an any rule. Okay, I agree that you can model it in a set-based way that avoids many of the problems. I am pretty concerned that this won't actually get coded this way, both because grant/revoke is easier and because non-enumerable sets aren't intuitively easy to map into many environments. But, obviously, I'm in the "rough" on the consensus here. I would ask that we do two things: review the language in the documents to ensure it is clear that the steps are 1) create a set 2) grant permissions to that set, and that grant/revoke will have untoward results; and add language to the document as a hint to developers that UIs make crystal clear how "blocked users" will be handled in the rules engine (i.e. "excepted from every grant"). regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 14:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dprr1-0005xw-Q8; Tue, 05 Jul 2005 14:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dprqx-0005wZ-Rx for simple@megatron.ietf.org; Tue, 05 Jul 2005 14:09:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01685 for ; Tue, 5 Jul 2005 14:09:01 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpsBw-0007yy-2Z for simple@ietf.org; Tue, 05 Jul 2005 14:30:45 -0400 Received: from [10.10.108.24] ([65.119.52.228]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j65I1rxk054590 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Jul 2005 13:01:54 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: From: Ben Campbell Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 13:01:47 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.730) Received-SPF: pass (nostrum.com: 65.119.52.228 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Cullen Jennings , Adam Roach , Orit Levin , 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="===============1902785066==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1902785066== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-104-545387050; protocol="application/pkcs7-signature" --Apple-Mail-104-545387050 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jul 5, 2005, at 12:36 PM, Rohan Mahy wrote: > Avshalom, > > I don't believe that the average user will go and manually > configure some MSRP proxy they've never heard of before. What is > the use case? > > Can anyone provide a *good* reason why you should be using > arbitrary random relays and why this is reasonable from a security > perspective. > > I personally hope that anyone enlightened enough to have heard of > MSRP will be at least enlightened enough to allow outbound TCP > connections from their network. I think the large deployed base of HTTP proxies would tend to prove your hope a false one. It is _very_ common for enterprise networks to only allow HTTP connections via a locally controlled proxy. Why would you expect an enterprise firewall admin to treat MSRP any different that it treats HTTP? Don't get me wrong; I'd love to see mandatory HTTP proxies go away too. But I am not wasting much breath on the effort to make it happen. > > thanks, > -rohan > > > On Jul 5, 2005, at 10:12, Avshalom Houri wrote: > >> Cullen Jennings wrote on 05/07/2005 08:04:01 PM: >> >> > On 7/4/05 12:59 AM, "Adam Roach" wrote: >> > >> > > I'm probably rehashing old arguments here, but I do have a >> reasonably >> > > strong feeling about this. If I want to go through my "home" >> relay for >> > > message logging purposes, but first need to go through a >> > > firewall-traversal relay at a client's site, I'd prefer to >> have the >> > > ability to do so without giving the client's relay an >> opportunity to >> > > intercept my "home" relay password. >> > >> > If we agree that the above use case is a valid use case, then I >> imagine this >> > discussion is probably over and all will agree we need to move >> to Digest. >> > Rohan had some sort of argument that amounted to "Don't do >> this". Can we >> > decide if we think this is a valid use case or not? >> > >> I think that it is a valid use case. The average user will not >> know that >> MSRP is sending the password on the clear over TLS. It will also >> be very hard >> to instruct users to use a gateway in the hotel for example for >> one protocol and >> not for the other. Most users do not even know what protocol their >> software is >> using. >> >> Avshalom >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > --Apple-Mail-104-545387050 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGRTCCAv4w ggJnoAMCAQICAw3JSzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTExMjEyMzM5WhcNMDYwMTExMjEyMzM5WjBiMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20x HzAdBgkqhkiG9w0BCQEWEGJlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCYWVM6KNDeP+5DdLWTRbBVLIVb4X4Yj6oYnbcNEPIRBuRGH8emhWbrCEBkDHaMQOEz izK6QEYjpoKcdmHLtKBWTMgzR/4danDoOjOeGfJ4fu9t1eXFsiVEyzf/ofZGhOzVR4q3ZfrotgjK kCTdrHpUBsyYRtRN5ZnBpxnkjVjJ77SAZ+JcSK+bs1dpohnRO6WL5ocfQXyMDzoUbnXDi1sUByd9 rCEa92lYpLKgEyr+7lkL3N56XofDV5Xzz9Y2+4GXKbTOjnN/RyNB3YDiXNB8DRclyiCvJINOFzjk 5R8AaGFs4lLoR3eZoAtidH0gp8DD1a+IEmHegjuRAmnVDqszAgMBAAGjPjA8MCwGA1UdEQQlMCOB D2JlbkBub3N0cnVtLmNvbYEQYmVuQGVzdGFjYWRvLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBACeJLe5lF2j4KsJLID+zX3t1TZvqhHqDrlpOL3ODVxK6ocXQE+bZwJX2bAhPm1Hb K8wMeeUK19VrqDnqoLzowtP+0hOjYV6CWf40OxdnjODcuSAqYsbmBBSkyRr6bQjzmqPCspJ70Dty AQ278NgOdlplxD0UJTfYKb0IPNUtuI3WMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMNyUswCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNzA1MTgwMTQ4WjAjBgkqhkiG9w0BCQQxFgQUPHTTM32dmUy+lpUPjNJKXF5o BdYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAw3JSzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMNyUswDQYJKoZIhvcNAQEBBQAEggEAhWpbVxMVFY5YiQ1KogiCDfv3 OAj7xlWg8jijF5kg+iA15+zlE8eJJWN90LQJcltgnBOMcyHPA4hBNNbo/yGadruhTK55l28vX59P xO2G1kQzBsH0cCZO9wthI+bRMvWWuQ9K158246wEZNW1KI2+Tau5DHCS1DoeNmUCWvN5NJKaiOtU C1cm3JvmqmvLEVJgrXbtmwZYwJDVhRu78ZQvQ7FwYgEozY6A2aoCYif+YU4c2N9tIJ1whhQb9zro cP4rEuDf9tusr7iWYuyy50xGJNuks+NyUkUf/XfgjlbruJQSVwfqOeZVaqTmZMNLPiYcvV+Zndvb o9UeajMFDPe3nAAAAAAAAA== --Apple-Mail-104-545387050-- --===============1902785066== 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 --===============1902785066==-- From simple-bounces@ietf.org Tue Jul 05 14:09:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprrU-0006IH-VJ; Tue, 05 Jul 2005 14:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprrT-0006Hc-D9 for simple@megatron.ietf.org; Tue, 05 Jul 2005 14:09:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02090 for ; Tue, 5 Jul 2005 14:09:31 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dps7R-0007iN-3C for simple@ietf.org; Tue, 05 Jul 2005 14:26:08 -0400 Received: from [10.10.108.24] ([65.119.52.228]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j65Hsh8S053982 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Jul 2005 12:54:44 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> From: Ben Campbell Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 12:54:37 -0500 To: Cullen Jennings X-Mailer: Apple Mail (2.730) Received-SPF: pass (nostrum.com: 65.119.52.228 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Rohan Mahy , Orit Levin , 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="===============1371242679==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1371242679== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-103-544956960; protocol="application/pkcs7-signature" --Apple-Mail-103-544956960 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jul 5, 2005, at 12:04 PM, Cullen Jennings wrote: > On 7/4/05 12:59 AM, "Adam Roach" wrote: > > >> I'm probably rehashing old arguments here, but I do have a reasonably >> strong feeling about this. If I want to go through my "home" relay >> for >> message logging purposes, but first need to go through a >> firewall-traversal relay at a client's site, I'd prefer to have the >> ability to do so without giving the client's relay an opportunity to >> intercept my "home" relay password. >> > > If we agree that the above use case is a valid use case, then I > imagine this > discussion is probably over and all will agree we need to move to > Digest. > Rohan had some sort of argument that amounted to "Don't do this". > Can we > decide if we think this is a valid use case or not? > So, I did some more thinking about this over the weekend, and it seems to me that we have already implied this use case by allowing the telescoping of AUTH. (That is, the ability to send AUTH to a second (or third etc) relay via the first.) What other use cases do we have for that mechanism other than the one Adam described? Or more generally, what other use cases do we have for the telescoping mechanism where the first and subsequent relays are all in the same administrative domain, so that revealing your second-relay password to the first relay is a non-issue? So, my concrete proposal is that we either solve the password-reveal issue, or we remove the AUTH telescoping mechanism. > > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > --Apple-Mail-103-544956960 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGRTCCAv4w ggJnoAMCAQICAw3JSzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTExMjEyMzM5WhcNMDYwMTExMjEyMzM5WjBiMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20x HzAdBgkqhkiG9w0BCQEWEGJlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCYWVM6KNDeP+5DdLWTRbBVLIVb4X4Yj6oYnbcNEPIRBuRGH8emhWbrCEBkDHaMQOEz izK6QEYjpoKcdmHLtKBWTMgzR/4danDoOjOeGfJ4fu9t1eXFsiVEyzf/ofZGhOzVR4q3ZfrotgjK kCTdrHpUBsyYRtRN5ZnBpxnkjVjJ77SAZ+JcSK+bs1dpohnRO6WL5ocfQXyMDzoUbnXDi1sUByd9 rCEa92lYpLKgEyr+7lkL3N56XofDV5Xzz9Y2+4GXKbTOjnN/RyNB3YDiXNB8DRclyiCvJINOFzjk 5R8AaGFs4lLoR3eZoAtidH0gp8DD1a+IEmHegjuRAmnVDqszAgMBAAGjPjA8MCwGA1UdEQQlMCOB D2JlbkBub3N0cnVtLmNvbYEQYmVuQGVzdGFjYWRvLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBACeJLe5lF2j4KsJLID+zX3t1TZvqhHqDrlpOL3ODVxK6ocXQE+bZwJX2bAhPm1Hb K8wMeeUK19VrqDnqoLzowtP+0hOjYV6CWf40OxdnjODcuSAqYsbmBBSkyRr6bQjzmqPCspJ70Dty AQ278NgOdlplxD0UJTfYKb0IPNUtuI3WMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMNyUswCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNzA1MTc1NDM4WjAjBgkqhkiG9w0BCQQxFgQUlnBRbgh5AuZTCXVKbReqbAFN SQEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAw3JSzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMNyUswDQYJKoZIhvcNAQEBBQAEggEAABsMzmn++etaUm4OCpnRld/h srwpY+nws3JuscB1S4hZDdhUgmbjmjVnMH+wpF2uy+ZIaWEE9KIt6eg2yk9W6FBkq96WcKsul/ts eyttPoUMooCJihr43g2Q6ZyK4Xx5jZ512WEpM0SoLsDyaFkKn4LDwx1Re8e7Q2zWxzvQbp//Z7/J RdZ/DayOYC2EAewgWfVWjTdZtPdQ9TIZ7zD1aWMLiYfkJprCrZXWqIGY34NVXGvMopVhkwT6pjRg x0aBAhePNzaHd0c9Fa+bM8TJipOiAezrXKLMb5eJhvGTspZIPFtUiwYaMaq5XmUMl5OhwEknCFAC OgskY6sNi8dO4QAAAAAAAA== --Apple-Mail-103-544956960-- --===============1371242679== 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 --===============1371242679==-- From simple-bounces@ietf.org Tue Jul 05 14:25:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps7A-0008WC-8q; Tue, 05 Jul 2005 14:25:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps75-0008Ti-Pt for simple@megatron.ietf.org; Tue, 05 Jul 2005 14:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03650 for ; Tue, 5 Jul 2005 14:25:38 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpsNF-0000TH-Dr for simple@ietf.org; Tue, 05 Jul 2005 14:42:27 -0400 Received: from [10.10.108.24] ([65.119.52.228]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j65IBZP2055520 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 5 Jul 2005 13:11:36 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <42CAC84B.3040506@nokia.com> References: <42CAC84B.3040506@nokia.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <246394C9-B9AA-4D34-A6C2-DD44A0808627@nostrum.com> From: Ben Campbell Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication in MSRP relays extension Date: Tue, 5 Jul 2005 13:11:28 -0500 To: Aki Niemi X-Mailer: Apple Mail (2.730) Received-SPF: pass (nostrum.com: 65.119.52.228 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: ext Cullen Jennings , Rohan Mahy , Orit Levin , 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="===============2144998026==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============2144998026== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-105-545968758; protocol="application/pkcs7-signature" --Apple-Mail-105-545968758 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jul 5, 2005, at 12:50 PM, Aki Niemi wrote: > Hi, > > I don't think this is a valid use case. If we are talking about > corporate users here (and I assume we are), I have a hard time > seeing MSRP logged via anything other than a VPN-tunnel along with > other traffic the users generate (such as email). And VPNs seem to > pass firewalls quite well already. > I have personally worked at no less than 3 enterprise sites that explicitly denied the use of outbound VPN, because they believed it 1) allowed data to leave the network they could not monitor, and 2) potentially created an uncontrolled path for things to come into the network. One of them even disallowed any analog phone lines in the building because people might connect modems to them, with exactly the same rational. As I have mentioned several times, firewall policy that locks down all communication except via locally-controlled proxies is common. There are lots of so-called security consultants out there claiming it is necessary, and lots of so-called security auditors that will mark you down if you don't do it. > Cheers, > Aki > > ext Cullen Jennings wrote: > >> On 7/4/05 12:59 AM, "Adam Roach" wrote: >> >>> I'm probably rehashing old arguments here, but I do have a >>> reasonably >>> strong feeling about this. If I want to go through my "home" >>> relay for >>> message logging purposes, but first need to go through a >>> firewall-traversal relay at a client's site, I'd prefer to have the >>> ability to do so without giving the client's relay an opportunity to >>> intercept my "home" relay password. >>> >> If we agree that the above use case is a valid use case, then I >> imagine this >> discussion is probably over and all will agree we need to move to >> Digest. >> Rohan had some sort of argument that amounted to "Don't do this". >> Can we >> decide if we think this is a valid use case or not? >> _______________________________________________ >> 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 > --Apple-Mail-105-545968758 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGRTCCAv4w ggJnoAMCAQICAw3JSzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTExMjEyMzM5WhcNMDYwMTExMjEyMzM5WjBiMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20x HzAdBgkqhkiG9w0BCQEWEGJlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCYWVM6KNDeP+5DdLWTRbBVLIVb4X4Yj6oYnbcNEPIRBuRGH8emhWbrCEBkDHaMQOEz izK6QEYjpoKcdmHLtKBWTMgzR/4danDoOjOeGfJ4fu9t1eXFsiVEyzf/ofZGhOzVR4q3ZfrotgjK kCTdrHpUBsyYRtRN5ZnBpxnkjVjJ77SAZ+JcSK+bs1dpohnRO6WL5ocfQXyMDzoUbnXDi1sUByd9 rCEa92lYpLKgEyr+7lkL3N56XofDV5Xzz9Y2+4GXKbTOjnN/RyNB3YDiXNB8DRclyiCvJINOFzjk 5R8AaGFs4lLoR3eZoAtidH0gp8DD1a+IEmHegjuRAmnVDqszAgMBAAGjPjA8MCwGA1UdEQQlMCOB D2JlbkBub3N0cnVtLmNvbYEQYmVuQGVzdGFjYWRvLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBACeJLe5lF2j4KsJLID+zX3t1TZvqhHqDrlpOL3ODVxK6ocXQE+bZwJX2bAhPm1Hb K8wMeeUK19VrqDnqoLzowtP+0hOjYV6CWf40OxdnjODcuSAqYsbmBBSkyRr6bQjzmqPCspJ70Dty AQ278NgOdlplxD0UJTfYKb0IPNUtuI3WMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMNyUswCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNzA1MTgxMTI5WjAjBgkqhkiG9w0BCQQxFgQU5JlKdSunV7eTDd11pDS3oKgj J/UweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAw3JSzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMNyUswDQYJKoZIhvcNAQEBBQAEggEAbqpFuPpgmbHmJaXAoUFzwibd vCOqEOz/H8aNPNhj3nzklGe8KtmoRTgZRq0YSf2JBmz/M4EAdKodjLN0MS5K3XH7+SBQGvW0ognP 8n0QMRqJF9sMDQIlRk0B1KcgLZsnNnz2bewkwmFKGkhIsZ2zGHlf/gQeGaFiXgDaJCnEZT9uMmxs XAigOMTzCILpdV0XVgVYrin1j9ToO0GWV36bdeIFNi5aav5PpX0n2UOhATOSoNt3mWYGu6+PfKV4 WdnKYsG8Lead9GqZDzhzR2Pi+Y4m/9tGINhqs4p4CqSCTkHS3ITvOM2eehgtAzvc3fPhiCbQlZcz PdAV8SB7qS68GwAAAAAAAA== --Apple-Mail-105-545968758-- --===============2144998026== 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 --===============2144998026==-- From simple-bounces@ietf.org Tue Jul 05 14:25:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps7G-00007v-Dq; Tue, 05 Jul 2005 14:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dps7E-00007B-9q for simple@megatron.ietf.org; Tue, 05 Jul 2005 14:25:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03792 for ; Tue, 5 Jul 2005 14:25:50 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpsIg-0000JX-Gh for simple@ietf.org; Tue, 05 Jul 2005 14:37:42 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j65I9t127371; Tue, 5 Jul 2005 11:09:55 -0700 In-Reply-To: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> References: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0bba5d6bb35fc2c229ff4283958aab4c@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 11:09:42 -0700 To: Ben Campbell X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 5, 2005, at 10:54, Ben Campbell wrote: > > > On Jul 5, 2005, at 12:04 PM, Cullen Jennings wrote: > >> On 7/4/05 12:59 AM, "Adam Roach" wrote: >> >> >>> I'm probably rehashing old arguments here, but I do have a reasonably >>> strong feeling about this. If I want to go through my "home" relay >>> for >>> message logging purposes, but first need to go through a >>> firewall-traversal relay at a client's site, I'd prefer to have the >>> ability to do so without giving the client's relay an opportunity to >>> intercept my "home" relay password. >>> >> >> If we agree that the above use case is a valid use case, then I >> imagine this >> discussion is probably over and all will agree we need to move to >> Digest. >> Rohan had some sort of argument that amounted to "Don't do this". Can >> we >> decide if we think this is a valid use case or not? >> > > So, I did some more thinking about this over the weekend, and it seems > to me that we have already implied this use case by allowing the > telescoping of AUTH. (That is, the ability to send AUTH to a second > (or third etc) relay via the first.) What other use cases do we have > for that mechanism other than the one Adam described? Or more > generally, what other use cases do we have for the telescoping > mechanism where the first and subsequent relays are all in the same > administrative domain, so that revealing your second-relay password to > the first relay is a non-issue? AUTH telescoping is useful in large enterprises (same administrative domain) where there is an internal relay and an external relay. The external relay farm services the entire company and might do additional logging or alerts on keywords. You only use the external relay when talking with someone outside your administrative domain. This is a fairly typical usage, and it is precisely the example that is given in the draft. thanks, -rohan > So, my concrete proposal is that we either solve the password-reveal > issue, or we remove the AUTH telescoping mechanism. > > >> >> >> >> >> >> _______________________________________________ >> 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 Tue Jul 05 14:58:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpscV-0004E6-Jn; Tue, 05 Jul 2005 14:58:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpscG-0003mr-RI for simple@megatron.ietf.org; Tue, 05 Jul 2005 14:58:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07082 for ; Tue, 5 Jul 2005 14:57:52 -0400 (EDT) Received: from mailrelay.eurospot.com ([62.39.81.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpssc-0002lg-3E for simple@ietf.org; Tue, 05 Jul 2005 15:14:57 -0400 Received: from [192.168.50.28] (unknown [82.109.138.58]) by mailrelay.eurospot.com (Postfix) with ESMTP id 006FE286D0E; Tue, 5 Jul 2005 20:46:51 +0200 (CEST) In-Reply-To: <0bba5d6bb35fc2c229ff4283958aab4c@ekabal.com> References: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> <0bba5d6bb35fc2c229ff4283958aab4c@ekabal.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 20:46:57 +0200 To: Rohan Mahy X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org (as a working group chair) Ok, it is clear that people have concerns with Basic as the authentication mechanism for MSRP Relays. It is also clear that the 2 people advocating Basic (Aki and Rohan) have not presented any strong argument against Digest nor have they clearly solved the concerns that people have with Basic. Digest resolves those concerns and there are no technical drawbacks with it. The majority of contributors to this thread either want Digest or do not object to using Digest. That is rough consensus to me. Unless you tell me you will commit suicide if Basic is not used, I am going to instruct the editors to rewrite the relevant sections to remove Basic and re-introduce Digest as the Authentication mechanism. In the mean time, please remember that a WGLC have been issued for MSRP relay draft. Please send your comments in a.s.a.p. Regards, Hisham SIMPLE WG co-chair On Jul 5, 2005, at 8:09 PM, Rohan Mahy wrote: > > On Jul 5, 2005, at 10:54, Ben Campbell wrote: > >> >> >> On Jul 5, 2005, at 12:04 PM, Cullen Jennings wrote: >> >>> On 7/4/05 12:59 AM, "Adam Roach" wrote: >>> >>> >>>> I'm probably rehashing old arguments here, but I do have a >>>> reasonably >>>> strong feeling about this. If I want to go through my "home" relay >>>> for >>>> message logging purposes, but first need to go through a >>>> firewall-traversal relay at a client's site, I'd prefer to have the >>>> ability to do so without giving the client's relay an opportunity to >>>> intercept my "home" relay password. >>>> >>> >>> If we agree that the above use case is a valid use case, then I >>> imagine this >>> discussion is probably over and all will agree we need to move to >>> Digest. >>> Rohan had some sort of argument that amounted to "Don't do this". >>> Can we >>> decide if we think this is a valid use case or not? >>> >> >> So, I did some more thinking about this over the weekend, and it >> seems to me that we have already implied this use case by allowing >> the telescoping of AUTH. (That is, the ability to send AUTH to a >> second (or third etc) relay via the first.) What other use cases do >> we have for that mechanism other than the one Adam described? Or more >> generally, what other use cases do we have for the telescoping >> mechanism where the first and subsequent relays are all in the same >> administrative domain, so that revealing your second-relay password >> to the first relay is a non-issue? > > AUTH telescoping is useful in large enterprises (same administrative > domain) where there is an internal relay and an external relay. The > external relay farm services the entire company and might do > additional logging or alerts on keywords. You only use the external > relay when talking with someone outside your administrative domain. > This is a fairly typical usage, and it is precisely the example that > is given in the draft. > > thanks, > -rohan > > >> So, my concrete proposal is that we either solve the password-reveal >> issue, or we remove the AUTH telescoping mechanism. >> >> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Tue Jul 05 15:14:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpssM-0002q8-LF; Tue, 05 Jul 2005 15:14:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpss6-0002gM-83 for simple@megatron.ietf.org; Tue, 05 Jul 2005 15:14:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09767 for ; Tue, 5 Jul 2005 15:14:13 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DptBR-0004lP-5u for simple@ietf.org; Tue, 05 Jul 2005 15:34:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2005 12:06:20 -0700 X-IronPort-AV: i="3.93,261,1115017200"; d="scan'208"; a="196440566:sNHT28148276" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j65J6G6p010508; Tue, 5 Jul 2005 12:06:17 -0700 (PDT) Received: from [10.0.1.3] ([10.21.145.120]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 12:10:37 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 05 Jul 2005 15:06:12 -0400 From: Cullen Jennings To: Rohan Mahy , Orit Levin , Adam Roach , Avshalom Houri , Aki Niemi Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Jul 2005 19:10:37.0318 (UTC) FILETIME=[3A00FA60:01C58195] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: [Simple] Digest Was: rodent stuck in tarpit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Way back at the being of this thread, Rohan put out some questions about how to do Digest. I think it would be good to get talking about those as well as proposed text that need to change to move to digest. If anyone wants to help with text, as always, appreciated and the XML is at http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-rela ys.xml Rohan's questions/proposal follows - can folks comment on how resolve open items.... On 6/20/05 6:44 PM, "Rohan Mahy" wrote: > When I originally tried to map the draft onto Digest, I was planning to > do something like this: > > - realm is a string provided by the server. it SHOULD be the host name > of the relay. > - the domains parameter is ignored > - note that the nonce algorithm based on ETags doesn't work > - do not support auth-int, but always include the qop parameter with > auth > - the digest-uri parameter is the right-most URI in the To-Path header > - the alg parameter is ??? > - the cnonce and the nonce-count MUST be sent > - the Method from A2 is always AUTH > - there is never a body for AUTH so A2 is just AUTH: plus the > Request-URI > - I have no idea what to do about MD5 vs. MD5-sess. > - I have no idea whether the nextnonce parameter is useful here. > - I don't think the response authentication parameter is useful at all. > However, the security considerations needs to describe what would or > would not be protected here. Remember that we have no integrity over > the Use-Path header from client to outermost relay even if we use this, > unless we redefine the A2 to include the value of the Use-Path header > instead of the entity-body. On 7/5/05 2:46 PM, "Hisham Khartabil" wrote: > (as a working group chair) > > Ok, it is clear that people have concerns with Basic as the > authentication mechanism for MSRP Relays. It is also clear that the 2 > people advocating Basic (Aki and Rohan) have not presented any strong > argument against Digest nor have they clearly solved the concerns that > people have with Basic. Digest resolves those concerns and there are no > technical drawbacks with it. > > The majority of contributors to this thread either want Digest or do > not object to using Digest. That is rough consensus to me. > > Unless you tell me you will commit suicide if Basic is not used, I am > going to instruct the editors to rewrite the relevant sections to > remove Basic and re-introduce Digest as the Authentication mechanism. > > In the mean time, please remember that a WGLC have been issued for MSRP > relay draft. Please send your comments in a.s.a.p. > > Regards, > Hisham > SIMPLE WG co-chair _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 15:47:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptOg-0001SF-Ue; Tue, 05 Jul 2005 15:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptOb-0001Qq-Nr for simple@megatron.ietf.org; Tue, 05 Jul 2005 15:47:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14515 for ; Tue, 5 Jul 2005 15:47:49 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DptbS-0002Fd-Dw for simple@ietf.org; Tue, 05 Jul 2005 16:01:11 -0400 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j65JWGgJ061800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2005 14:32:17 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <42CAE02F.5080906@nostrum.com> Date: Tue, 05 Jul 2005 14:31:59 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Orit Levin , Avshalom Houri , Aki Niemi , "simple@ietf.org" Subject: [Simple] Re: Digest Was: rodent stuck in tarpit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Cullen Jennings wrote: > >Rohan's questions/proposal follows - can folks comment on how resolve open >items.... > >On 6/20/05 6:44 PM, "Rohan Mahy" wrote: > > >>When I originally tried to map the draft onto Digest, I was planning to >>do something like this: >> >>- realm is a string provided by the server. it SHOULD be the host name >>of the relay. >> >> Host name or domain name -- I think this would be up to the whoever deploys it. If they want a single password across all their MSRP relays, they share a common realm. I'm not sure the document needs to say too much about this. >>- the domains parameter is ignored >> >> Maybe I'm becoming senile, but I can't recall what this might be talking about, and RFC 2617 doesn't give me any clues. >>- note that the nonce algorithm based on ETags doesn't work >> >> So authentication will likely need to be stateful. >>- do not support auth-int, but always include the qop parameter with >>auth >> >> Sounds reasonable. We can always add an S/MIME mechanism if we need integrity protection. >>- the digest-uri parameter is the right-most URI in the To-Path header >> >> Yes. >>- the alg parameter is ??? >> >> MD5, probably (modulo any discussions we have on MD5-sess handling). I think we want to be able to re-use as much code as possible from any SIP digest implementations people have in their clients. >>- the cnonce and the nonce-count MUST be sent >> >> Sounds good. >>- the Method from A2 is always AUTH >> >> I agree, in a round-about sort of way. It should always match the method, and we're doing authentication in AUTH requests. >>- there is never a body for AUTH so A2 is just AUTH: plus the >>Request-URI >> >> Yep >>- I have no idea what to do about MD5 vs. MD5-sess. >> >> The handling of session mode in RFC 2617 is extremely ambiguous. I have poked and prodded the HTTP community and key players within it to try to get some clarification, and the net result seems to be that no one really cares because no one really implements it. (For the morbidly curious, you can read my summary of the problem at http://lists.w3.org/Archives/Public/ietf-http-wg/2004OctDec/0039.html). Until this issue is clarified, I don't think specifying MD5-sess is viable, since it is fundamentally unimplementable. >>- I have no idea whether the nextnonce parameter is useful here. >> >> I believe it is. The server can send nextnonces in the response to AUTH request which the client can then use when they refresh their AUTH binding -- this reduces all non-initial AUTH requests to one round trip instead of two. >>- I don't think the response authentication parameter is useful at all. >> >> Agreed. >>However, the security considerations needs to describe what would or >>would not be protected here. >> I don't think we're looking for an integrity protection mechanism here; I think we're looking for an authentication mechanism. It's fine with me if the security section basically says, "the use of digest authentication in MSRP provides no integrity protection, and is to be used as an authentication mechanism only." /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 17:01:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpuY1-0000x3-3G; Tue, 05 Jul 2005 17:01:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpuXu-0000uF-Na for simple@megatron.ietf.org; Tue, 05 Jul 2005 17:01:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27269 for ; Tue, 5 Jul 2005 17:01:26 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpukg-0005bJ-4g for simple@ietf.org; Tue, 05 Jul 2005 17:14:46 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j65KkhHP031770; Tue, 5 Jul 2005 20:46:43 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 16:46:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] element issue for common policy Date: Tue, 5 Jul 2005 16:46:42 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502F97@stntexch03.cis.neustar.com> Thread-Topic: [Simple] element issue for common policy Thread-Index: AcV+v1K5I2K0mrgRQbGDsOsehWSn2QC4SKpg From: "Peterson, Jon" To: "Jonathan Rosenberg" , "Henning Schulzrinne" X-OriginalArrivalTime: 05 Jul 2005 20:46:43.0364 (UTC) FILETIME=[A6D5C640:01C581A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > Right. Put another way, putting an exception in the matching condition = > is just another way to define the set of users to whom the additive=20 > permissions apply. The only difference is that the set of people to = whom=20 > they apply is potentially large, but there is no change in the model. There is one substantive change to the model, I think. Previously in the = GEOPRIV work, we had the following design goal: if an external ruleset = (one included in the PIDF-LO object by reference) could not be accessed, = then the worst thing that could happen is the policies would be more = restrictive than they need to be. If a local ruleset has a rule that says everyone can have access to = element Y except Alice, and an external ruleset that says everyone can = have access to element Y except Carol... then it would seem that if the = external ruleset cannot be acquired by the policy implementer, this = results is a less restrictive policy. For the record, and as I said at the last SIMPLE meeting, I agree with = Ted that the efficacy of negative permissions in this sort of system is = very limited, and that policies along these lines are not likely to = yield useful protections for a presentity. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 20:56:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyDQ-00011b-9r; Tue, 05 Jul 2005 20:56:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyDM-0000xl-BU for simple@megatron.ietf.org; Tue, 05 Jul 2005 20:56:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28766 for ; Tue, 5 Jul 2005 20:56:33 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpyOZ-00039D-Mx for simple@ietf.org; Tue, 05 Jul 2005 21:08:12 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j660eGuR026901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jul 2005 20:40:16 -0400 (EDT) Message-ID: <42CB2871.1060000@cs.columbia.edu> Date: Tue, 05 Jul 2005 20:40:17 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" Subject: Re: [Simple] element issue for common policy References: <24EAE5D4448B9D4592C6D234CBEBD59701502F97@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502F97@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Ted Hardie , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > There is one substantive change to the model, I think. Previously in > the GEOPRIV work, we had the following design goal: if an external > ruleset (one included in the PIDF-LO object by reference) could not > be accessed, then the worst thing that could happen is the policies > would be more restrictive than they need to be. > > If a local ruleset has a rule that says everyone can have access to > element Y except Alice, and an external ruleset that says everyone > can have access to element Y except Carol... then it would seem that > if the external ruleset cannot be acquired by the policy implementer, > this results is a less restrictive policy. I'm not sure this is true, but maybe we're talking about two different cases. Let's take your example: (R1) Anybody except Alice can access Y (R2) Anybody except Carol can access Y For now, assume that R1 and R2 are accessible. By the standard rules, permissions are *additive*, thus, by R1, Carol can access Y. (Carol matches R1 and accumulates all the permissions that R1 grants.) Similarly, Alice can also access by virtue by R2. Thus, the matching constraints don't restrict any access. This is not a new problem, even without these matching constraints. [If you grant Bob very narrow right but Bob is also part of a domain match with "better" access, Bob will get the domain rights.] If (R1) is inaccessible, things work as expected: Carol can no longer see Y, even though she could before. Thus, the matching constraints don't impair the additivity and privacy safety, but they do mean that exceptions have to be in every domain-based rule to be meaningful, i.e., (R1') Anybody except Alice,Carol can access Y Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 05 21:12:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpySz-0004s0-2Z; Tue, 05 Jul 2005 21:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpySK-0004Ku-Od for simple@megatron.ietf.org; Tue, 05 Jul 2005 21:12:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00010 for ; Tue, 5 Jul 2005 21:12:00 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpyo8-0005IW-1h for simple@ietf.org; Tue, 05 Jul 2005 21:34:36 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j6615W129199; Tue, 5 Jul 2005 18:05:32 -0700 In-Reply-To: References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <07917b8077cf7036f58bb14b74f1c777@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 18:05:18 -0700 To: Ben Campbell X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Avshalom Houri , "simple@ietf.org" , Adam Roach 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 5, 2005, at 11:01, Ben Campbell wrote: > > On Jul 5, 2005, at 12:36 PM, Rohan Mahy wrote: > >> Avshalom, >> >> I don't believe that the average user will go and manually configure >> some MSRP proxy they've never heard of before. What is the use case? >> >> Can anyone provide a *good* reason why you should be using arbitrary >> random relays and why this is reasonable from a security perspective. >> >> I personally hope that anyone enlightened enough to have heard of >> MSRP will be at least enlightened enough to allow outbound TCP >> connections from their network. > > I think the large deployed base of HTTP proxies would tend to prove > your hope a false one. It is _very_ common for enterprise networks to > only allow HTTP connections via a locally controlled proxy. Why would > you expect an enterprise firewall admin to treat MSRP any different > that it treats HTTP? > > Don't get me wrong; I'd love to see mandatory HTTP proxies go away > too. But I am not wasting much breath on the effort to make it happen. If you are "inside" an enterprise network then typically you have credentials to its enterprise resources and would only use the enterprise MSRP relays. I have never used a hotspot or hotel internet access provider that required me to use their HTTP proxy or did not allow me to make outbound TCP connections. For the previous 7 years I travelled extensively and was able to connect using SSH port forwarding in a number of situations where my colleagues could not get their VPN software to work. Outbound TCP works on public networks. If you managed to get onto a private network you would need credentials to use their relay anyway. Why use another relay in addition? thanks, -rohan >> >> thanks, >> -rohan >> >> >> On Jul 5, 2005, at 10:12, Avshalom Houri wrote: >> >>> Cullen Jennings wrote on 05/07/2005 08:04:01 PM: >>> >>> > On 7/4/05 12:59 AM, "Adam Roach" wrote: >>> > >>> > > I'm probably rehashing old arguments here, but I do have a >>> reasonably >>> > > strong feeling about this. If I want to go through my "home" >>> relay for >>> > > message logging purposes, but first need to go through a >>> > > firewall-traversal relay at a client's site, I'd prefer to have >>> the >>> > > ability to do so without giving the client's relay an >>> opportunity to >>> > > intercept my "home" relay password. >>> > >>> > If we agree that the above use case is a valid use case, then I >>> imagine this >>> > discussion is probably over and all will agree we need to move to >>> Digest. >>> > Rohan had some sort of argument that amounted to "Don't do this". >>> Can we >>> > decide if we think this is a valid use case or not? >>> > >>> I think that it is a valid use case. The average user will not know >>> that >>> MSRP is sending the password on the clear over TLS. It will also be >>> very hard >>> to instruct users to use a gateway in the hotel for example for one >>> protocol and >>> not for the other. Most users do not even know what protocol their >>> software is >>> using. >>> >>> Avshalom >>> >> >> >> _______________________________________________ >> 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 Tue Jul 05 21:12:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyT5-0004zZ-5A; Tue, 05 Jul 2005 21:12:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyT1-0004xK-Uw for simple@megatron.ietf.org; Tue, 05 Jul 2005 21:12:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00581 for ; Tue, 5 Jul 2005 21:12:44 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpygH-0004in-Ex for simple@ietf.org; Tue, 05 Jul 2005 21:26:29 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2005 20:58:33 -0400 X-IronPort-AV: i="3.93,263,1115006400"; d="scan'208"; a="61123098:sNHT1605610786" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j660wVbd021479; Tue, 5 Jul 2005 20:58:32 -0400 (EDT) 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.211); Tue, 5 Jul 2005 20:58:31 -0400 Received: from [192.168.1.102] ([10.86.240.200]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Jul 2005 20:58:31 -0400 Message-ID: <42CB2CB6.3060404@cisco.com> Date: Tue, 05 Jul 2005 20:58:30 -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: Henning Schulzrinne Subject: Re: [Simple] element issue for common policy References: <24EAE5D4448B9D4592C6D234CBEBD59701502F97@stntexch03.cis.neustar.com> <42CB2871.1060000@cs.columbia.edu> In-Reply-To: <42CB2871.1060000@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2005 00:58:31.0440 (UTC) FILETIME=[D3F33900:01C581C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Ted Hardie , simple@ietf.org, "Peterson, Jon" 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org inline. Henning Schulzrinne wrote: > >> There is one substantive change to the model, I think. Previously in >> the GEOPRIV work, we had the following design goal: if an external >> ruleset (one included in the PIDF-LO object by reference) could not >> be accessed, then the worst thing that could happen is the policies >> would be more restrictive than they need to be. >> >> If a local ruleset has a rule that says everyone can have access to >> element Y except Alice, and an external ruleset that says everyone >> can have access to element Y except Carol... then it would seem that >> if the external ruleset cannot be acquired by the policy implementer, >> this results is a less restrictive policy. > > > I'm not sure this is true, but maybe we're talking about two different > cases. Let's take your example: > > (R1) Anybody except Alice can access Y > (R2) Anybody except Carol can access Y > > For now, assume that R1 and R2 are accessible. > > By the standard rules, permissions are *additive*, thus, by R1, Carol > can access Y. (Carol matches R1 and accumulates all the permissions that > R1 grants.) Similarly, Alice can also access by virtue by R2. Thus, the > matching constraints don't restrict any access. This is not a new > problem, even without these matching constraints. [If you grant Bob very > narrow right but Bob is also part of a domain match with "better" > access, Bob will get the domain rights.] I agree with Henning here. The problem is exactly the issue that Ted is concerned about; that folks will assume that if they have a rule that says "give Y to everyone except Alice", that this revocation of permissions from Alice occurs after the grants have all been accumulated. That experience can still be simulated with privacy safety if a web application keeps track of set of blocked users and adds them as an exception to each rule. As such, you wouldn't end up with rules like R1 and R2 above, you'd probably have: R1: grant Y to everyone except Alice and Carol R2: grant Z to everyone except Alice and Carol and this continues to have the desired property - if R1 cannot be fetched, less information is given out, not more. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Tue Jul 05 21:45:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpyyB-0005HZ-U7; Tue, 05 Jul 2005 21:44:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpyy8-0005Cw-Cc for simple@megatron.ietf.org; Tue, 05 Jul 2005 21:44:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03905 for ; Tue, 5 Jul 2005 21:44:51 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpzHc-0002mN-PN for simple@ietf.org; Tue, 05 Jul 2005 22:05:05 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j661a4129298; Tue, 5 Jul 2005 18:36:04 -0700 In-Reply-To: References: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> <0bba5d6bb35fc2c229ff4283958aab4c@ekabal.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 18:35:48 -0700 To: Hisham Khartabil X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , Adam Roach , "simple@ietf.org" , Rohan Mahy 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 5, 2005, at 11:46, Hisham Khartabil wrote: > (as a working group chair) > > Ok, it is clear that people have concerns with Basic as the > authentication mechanism for MSRP Relays. It is also clear that the 2 > people advocating Basic (Aki and Rohan) have not presented any strong > argument against Digest nor have they clearly solved the concerns that > people have with Basic. Digest resolves those concerns and there are > no technical drawbacks with it. > The majority of contributors to this thread either want Digest or do > not object to using Digest. That is rough consensus to me. 1) Done is a feature and perfect is the often the enemy of the good. The draft is done now if Basic is acceptable. "Not done" is a technical drawback. I raised several open issues with how you would map Digest to MSRP which are not resolved. More issues will crop up if we actually write text. 2) This disagreement appears to be between a very small number of people. The main desire for wanting Digest appears to be a use case (multiple relays per side in different administrative domains) that still does not have a well justified motivation. This doesn't seem like much of a consensus to me. > Unless you tell me you will commit suicide if Basic is not used, I am > going to instruct the editors to rewrite the relevant sections to > remove Basic and re-introduce Digest as the Authentication mechanism. I'm not planning to commit suicide, but my IETF work is currently happening at the expense of paid consulting work. Since I don't have credible text on the semantics and syntax of all the Digest parameters, nor a reasonable section for the Security Considerations section, its likely that I would just pass the baton to another editor. The reason that I did not "simply" finish the Digest specification earlier in the life of the draft was because as I dug deeper into it it seemed like a poorer and poorer fit. thanks, -rohan > In the mean time, please remember that a WGLC have been issued for > MSRP relay draft. Please send your comments in a.s.a.p. > > Regards, > Hisham > SIMPLE WG co-chair > > On Jul 5, 2005, at 8:09 PM, Rohan Mahy wrote: > >> >> On Jul 5, 2005, at 10:54, Ben Campbell wrote: >> >>> >>> >>> On Jul 5, 2005, at 12:04 PM, Cullen Jennings wrote: >>> >>>> On 7/4/05 12:59 AM, "Adam Roach" wrote: >>>> >>>> >>>>> I'm probably rehashing old arguments here, but I do have a >>>>> reasonably >>>>> strong feeling about this. If I want to go through my "home" relay >>>>> for >>>>> message logging purposes, but first need to go through a >>>>> firewall-traversal relay at a client's site, I'd prefer to have the >>>>> ability to do so without giving the client's relay an opportunity >>>>> to >>>>> intercept my "home" relay password. >>>>> >>>> >>>> If we agree that the above use case is a valid use case, then I >>>> imagine this >>>> discussion is probably over and all will agree we need to move to >>>> Digest. >>>> Rohan had some sort of argument that amounted to "Don't do this". >>>> Can we >>>> decide if we think this is a valid use case or not? >>>> >>> >>> So, I did some more thinking about this over the weekend, and it >>> seems to me that we have already implied this use case by allowing >>> the telescoping of AUTH. (That is, the ability to send AUTH to a >>> second (or third etc) relay via the first.) What other use cases do >>> we have for that mechanism other than the one Adam described? Or >>> more generally, what other use cases do we have for the telescoping >>> mechanism where the first and subsequent relays are all in the same >>> administrative domain, so that revealing your second-relay password >>> to the first relay is a non-issue? >> >> AUTH telescoping is useful in large enterprises (same administrative >> domain) where there is an internal relay and an external relay. The >> external relay farm services the entire company and might do >> additional logging or alerts on keywords. You only use the external >> relay when talking with someone outside your administrative domain. >> This is a fairly typical usage, and it is precisely the example that >> is given in the draft. >> >> thanks, >> -rohan >> >> >>> So, my concrete proposal is that we either solve the password-reveal >>> issue, or we remove the AUTH telescoping mechanism. >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Jul 06 00:21:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1Py-00033Y-0H; Wed, 06 Jul 2005 00:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1Pv-0002zu-TU for simple@megatron.ietf.org; Wed, 06 Jul 2005 00:21:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21743 for ; Wed, 6 Jul 2005 00:21:45 -0400 (EDT) Received: from ylpvm12-ext.prodigy.net ([207.115.57.43] helo=ylpvm12.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq1qq-0006f6-LV for simple@ietf.org; Wed, 06 Jul 2005 00:49:36 -0400 Received: from pimout5-ext.prodigy.net (pimout5-int.prodigy.net [207.115.4.21]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j664LfpJ018665 for ; Wed, 6 Jul 2005 00:21:41 -0400 X-ORBL: [70.249.148.178] Received: from [192.168.0.101] (ppp-70-249-148-178.dsl.rcsntx.swbell.net [70.249.148.178]) by pimout5-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j664LV0u229924; Wed, 6 Jul 2005 00:21:40 -0400 Message-ID: <42CB5C5B.9060307@nostrum.com> Date: Tue, 05 Jul 2005 23:21:47 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> In-Reply-To: <07917b8077cf7036f58bb14b74f1c777@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > For the previous 7 years I travelled extensively and was able to > connect using SSH port forwarding in a number of situations where my > colleagues could not get their VPN software to work. I'm not sure it's realistic to expect all MSRP users to be as sophisticated as you at circumventing administrative policies. In any case, if that kind of circumvention were the means by which we expected firewall traversal to be performed, we would be specifying the use of port 80 for MSRP. > Outbound TCP works on public networks. If you managed to get onto a > private network you would need credentials to use their relay anyway. > Why use another relay in addition? Imagine my employer is a public company, and they have a policy of logging all messages sent to and from my company-owned machine as a part of Sarbanes-Oxley record keeping. Alternately, imagine I'm a securities broker, and my company is required to log messages I send as a part of SEC regulations. These are realistic use cases that would administratively force me to send my messages through my company's relay. Further imagine that, in the course of business, I travel to customers' sites from time to time. Imagine those customers allow access only through designated proxies specific to the protocols they allow to pass. Perhaps they allow instant message sessions, but -- as a matter of administrative policy -- log all such inbound and outbound messages, and consequently require the use of their MSRP relay. I'm not going to argue that this is a reasonable thing for them to be doing; however, I can cite two different customers that our company currently has that have network configurations that are substantially similar to that description (modulo the use of proprietary IM protocols). I have spent time on their networks, and been forced to operate through their IM relays to perform instant messaging sessions. It is unrealistic to expect that they will change their administrative policy once MSRP is deployed, even if you and I think it's a stupid policy. In fact, I fully expect them to deploy MSRP relays that continue to allow them to log instant messages as they currently are doing. So you can say the use cases arise out of stupid regulations and stupid administrative policies -- and I can't disagree with you. However, I don't think it's realistic to assert that use cases involving relays in different administrative domains actually won't arise. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 00:42:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1kP-0001FI-1a; Wed, 06 Jul 2005 00:42:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1kI-0001Dq-4R for simple@megatron.ietf.org; Wed, 06 Jul 2005 00:42:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23873 for ; Wed, 6 Jul 2005 00:42:47 -0400 (EDT) Received: from ylpvm12-ext.prodigy.net ([207.115.57.43] helo=ylpvm12.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq2BC-0000k7-1F for simple@ietf.org; Wed, 06 Jul 2005 01:10:39 -0400 Received: from ylpvm01.prodigy.net (ylpvm01-int.prodigy.net [207.115.5.207]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j664gjpL017099 for ; Wed, 6 Jul 2005 00:42:45 -0400 Received: from [192.168.0.101] (ppp-70-249-148-178.dsl.rcsntx.swbell.net [70.249.148.178]) by ylpvm01.prodigy.net (8.13.4 dk-milter linux/8.13.4) with ESMTP id j664gjoB025293; Wed, 6 Jul 2005 00:42:45 -0400 Message-ID: <42CB6157.1010809@nostrum.com> Date: Tue, 05 Jul 2005 23:43:03 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> <0bba5d6bb35fc2c229ff4283958aab4c@ekabal.com> 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , "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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > 1) Done is a feature and perfect is the often the enemy of the good. I agree with your statement. It does not apply to the situation at hand. I am confident that basic authentication does not rise to the level of "good," and I hesitate to suggest that digest authentication is "perfect." I would characterize them more as "broken" and "acceptable," respectively. > The draft is done now if Basic is acceptable. "Not done" is a > technical drawback. I raised several open issues with how you would > map Digest to MSRP which are not resolved. If you're referring to the list that Cullen re-posted earlier today, I don't think they're intractible or even difficult, especially once you consider that all we're trying to do here is authenticate users, and not provide any level of integrity protection (which is where most of the questions you had seemed to stem from). In fact, the answers seem obvious to me: use a realm appropriate to the scope of the password (equivalent relays in a single domain); don't worry in any way about integrity (request or response); use MD5 to provide code re-use from SIP clients; don't use MD5-sess because it's aggressively underspecified; require cnonce and nonce-count; use the request method as the method; nextnonce use is optional and useful; and response authentication makes no sense. I agree that the text remains to be written, but as far as I can tell, the "open issues" have very straightforward answers. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 00:47:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1om-0004Hm-C7; Wed, 06 Jul 2005 00:47:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1oh-0004Fs-RZ for simple@megatron.ietf.org; Wed, 06 Jul 2005 00:47:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24578 for ; Wed, 6 Jul 2005 00:47:21 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq2Fc-0001VX-Ke for simple@ietf.org; Wed, 06 Jul 2005 01:15:13 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j664kx129855; Tue, 5 Jul 2005 21:46:59 -0700 In-Reply-To: <42CB5C5B.9060307@nostrum.com> References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 21:47:02 -0700 To: Adam Roach X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , Avshalom Houri , "simple@ietf.org" , Rohan Mahy 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 5, 2005, at 21:21, Adam Roach wrote: > Rohan Mahy wrote: > >> For the previous 7 years I travelled extensively and was able to >> connect using SSH port forwarding in a number of situations where my >> colleagues could not get their VPN software to work. > > > I'm not sure it's realistic to expect all MSRP users to be as > sophisticated as you at circumventing administrative policies. I wasn't circumventing anything. I just made an outbound TCP connection to the default port. It could have been trivially blocked, but nobody bothered because I was using public hotspots or hotel networks. > In any case, if that kind of circumvention were the means by which we > expected firewall traversal to be performed, we would be specifying > the use of port 80 for MSRP. Since it wasn't necessary to circumvent anything to make an outbound TCP connection from a hotspot I don't think it is necessary or useful to use port 80 for MSRP. >> Outbound TCP works on public networks. If you managed to get onto a >> private network you would need credentials to use their relay anyway. >> Why use another relay in addition? > > Imagine my employer is a public company, and they have a policy of > logging all messages sent to and from my company-owned machine as a > part of Sarbanes-Oxley record keeping. Alternately, imagine I'm a > securities broker, and my company is required to log messages I send > as a part of SEC regulations. These are realistic use cases that would > administratively force me to send my messages through my company's > relay. YES. You need to send your messages through ***YOUR*** company's relay. I have no problem with this. > Further imagine that, in the course of business, I travel to > customers' sites from time to time. Imagine those customers allow > access only through designated proxies specific to the protocols they > allow to pass. Perhaps they allow instant message sessions, but -- as > a matter of administrative policy -- log all such inbound and outbound > messages, and consequently require the use of their MSRP relay. I'm > not going to argue that this is a reasonable thing for them to be > doing; however, I can cite two different customers that our company > currently has that have network configurations that are substantially > similar to that description (modulo the use of proprietary IM > protocols). I have spent time on their networks, and been forced to > operate through their IM relays to perform instant messaging sessions. > It is unrealistic to expect that they will change their administrative > policy once MSRP is deployed, even if you and I think it's a stupid > policy. In fact, I fully expect them to deploy MSRP relays that > continue to allow them to log instant messages as they currently are > doing. If you have to log all your messages to Sarbanes-Oxley, you will also be required to use a VPN to go directly to your company. When you use the VPN you still only go through *YOUR* companies relay. Even if your company screwed up somehow, your company relay would have no reason to trust AUTH requests that came from an untrusted relay in another domain. How would your relay make such an authorization decision? thanks, -rohan > So you can say the use cases arise out of stupid regulations and > stupid administrative policies -- and I can't disagree with you. > However, I don't think it's realistic to assert that use cases > involving relays in different administrative domains actually won't > arise. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 01:00:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq215-00053D-F5; Wed, 06 Jul 2005 01:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq212-00051x-9G for simple@megatron.ietf.org; Wed, 06 Jul 2005 01:00:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26118 for ; Wed, 6 Jul 2005 01:00:07 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq2Rx-0003Zz-0y for simple@ietf.org; Wed, 06 Jul 2005 01:27:57 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j664xu129916; Tue, 5 Jul 2005 21:59:56 -0700 In-Reply-To: <42CB6157.1010809@nostrum.com> References: <030C9319-BED5-4452-9C6A-959F3C80E9D3@nostrum.com> <0bba5d6bb35fc2c229ff4283958aab4c@ekabal.com> <42CB6157.1010809@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 21:59:41 -0700 To: Adam Roach X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , "simple@ietf.org" , Rohan Mahy 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 5, 2005, at 21:43, Adam Roach wrote: > Rohan Mahy wrote: > >> 1) Done is a feature and perfect is the often the enemy of the good. > > > I agree with your statement. > > It does not apply to the situation at hand. > > I am confident that basic authentication does not rise to the level of > "good," and I hesitate to suggest that digest authentication is > "perfect." I would characterize them more as "broken" and > "acceptable," respectively. I guess its not surprising that we disagree. >> The draft is done now if Basic is acceptable. "Not done" is a >> technical drawback. I raised several open issues with how you would >> map Digest to MSRP which are not resolved. > > > If you're referring to the list that Cullen re-posted earlier today, I > don't think they're intractible or even difficult, especially once you > consider that all we're trying to do here is authenticate users, and > not provide any level of integrity protection (which is where most of > the questions you had seemed to stem from). > > In fact, the answers seem obvious to me: use a realm appropriate to > the scope of the password (equivalent relays in a single domain); > don't worry in any way about integrity (request or response); use MD5 > to provide code re-use from SIP clients; don't use MD5-sess because > it's aggressively underspecified; require cnonce and nonce-count; use > the request method as the method; nextnonce use is optional and > useful; and response authentication makes no sense. I agree that the > text remains to be written, but as far as I can tell, the "open > issues" have very straightforward answers. The list I came up with is a short list of the semantics that need to be specified. I did not make an exhaustive list of the new threats we would need to account for and what information we would need to include in Digest in this case. For example, if you are sending an AUTH request through a relay in another administrative domain it think it would be irresponsible to skip integrity protection over the Use-Path header. I don't think the security in the use case you are trying to motivate is "straightforward" if you use Digest. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 01:26:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq2QI-0006M1-Pd; Wed, 06 Jul 2005 01:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq2QG-0006I0-Qv for simple@megatron.ietf.org; Wed, 06 Jul 2005 01:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28886 for ; Wed, 6 Jul 2005 01:26:12 -0400 (EDT) Received: from ylpvm12-ext.prodigy.net ([207.115.57.43] helo=ylpvm12.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq2rB-0006il-43 for simple@ietf.org; Wed, 06 Jul 2005 01:54:02 -0400 Received: from ylpvm01.prodigy.net (ylpvm01-int.prodigy.net [207.115.5.207]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j665Q7pL019025 for ; Wed, 6 Jul 2005 01:26:07 -0400 Received: from [192.168.0.101] (ppp-70-249-148-178.dsl.rcsntx.swbell.net [70.249.148.178]) by ylpvm01.prodigy.net (8.13.4 dk-milter linux/8.13.4) with ESMTP id j665Q7hm012465; Wed, 6 Jul 2005 01:26:07 -0400 Message-ID: <42CB6B82.6010403@nostrum.com> Date: Wed, 06 Jul 2005 00:26:26 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> In-Reply-To: <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > If you have to log all your messages to Sarbanes-Oxley, you will also > be required to use a VPN to go directly to your company. And if the site that I've visited blocks outbound VPNs because they allow insufficient monitoring? Ben has already asserted that he has worked with one company that does so. I agree that what you are proposing is one potential solution that can be applied in specific scenarios. However, I assert by way of actual deployments that there are realistic scenarios in which it can not be applied but which multiple relays in differing administrative domains can. > Even if your company screwed up somehow, your company relay would have > no reason to trust AUTH requests that came from an untrusted relay in > another domain. How would your relay make such an authorization decision? How do HTTP servers trust Digest authentication that arrives by way of an HTTP proxy? If my understanding is correct, they issue a challenge, and validate that the response to the challenge demonstrates possession of a shared secret. What am I missing? How does this not apply in the multi-relay case? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 01:59:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq2wn-0006gX-Uh; Wed, 06 Jul 2005 01:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq2wf-0006Xp-CH for simple@megatron.ietf.org; Wed, 06 Jul 2005 01:59:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03788 for ; Wed, 6 Jul 2005 01:59:40 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq3NZ-0000ag-O9 for simple@ietf.org; Wed, 06 Jul 2005 02:27:31 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j665vR130148; Tue, 5 Jul 2005 22:57:27 -0700 In-Reply-To: <42CB6B82.6010403@nostrum.com> References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> <42CB6B82.6010403@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <21836729687ea7c75767c7b49617b2e5@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Tue, 5 Jul 2005 22:57:27 -0700 To: Adam Roach X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , Avshalom Houri , "simple@ietf.org" , Rohan Mahy 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 5, 2005, at 22:26, Adam Roach wrote: > Rohan Mahy wrote: > >> If you have to log all your messages to Sarbanes-Oxley, you will also >> be required to use a VPN to go directly to your company. > > > And if the site that I've visited blocks outbound VPNs because they > allow insufficient monitoring? Ben has already asserted that he has > worked with one company that does so. I agree that what you are > proposing is one potential solution that can be applied in specific > scenarios. However, I assert by way of actual deployments that there > are realistic scenarios in which it can not be applied but which > multiple relays in differing administrative domains can. > >> Even if your company screwed up somehow, your company relay would >> have no reason to trust AUTH requests that came from an untrusted >> relay in another domain. How would your relay make such an >> authorization decision? > > > How do HTTP servers trust Digest authentication that arrives by way of > an HTTP proxy? If my understanding is correct, they issue a challenge, > and validate that the response to the challenge demonstrates > possession of a shared secret. What am I missing? How does this not > apply in the multi-relay case? HTTP operates very differently. The HTTP Digest challenge is for a specific resource returned in a body that the User Agent is requesting. The HTTP server can apply response integrity to this body. If TLS is used, there is a command to the relay that tells it to get out of the way and just complete the TLS connection. Many proxies don't need to authenticate the user to work. A large number of them just record every transaction and watch for viruses and various other nasty things. MSRP authentication is used to fetch a forwarding URI that is supposed to remain secret. The provisions that prevent against open relays depend on trusting all the nodes on your "side" and verifying that the other side provided one of the secret URIs you provided. Relays will also verify the source of messages from the forwarding URI comes over the same path. This is authenticating for a very different reason and relying on a very different set of trust assumptions than an HTTP proxy. I'll point out that Jabber does not support arbitrary intermediaries and they are successfully deploying in plenty of banks, hospitals, and all the other regulated environments that have been cited as use cases. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 06:23:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq73a-0005Kf-I5; Wed, 06 Jul 2005 06:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq73V-0005GZ-PV for simple@megatron.ietf.org; Wed, 06 Jul 2005 06:23:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19163 for ; Wed, 6 Jul 2005 06:22:57 -0400 (EDT) Received: from ylpvm15-ext.prodigy.net ([207.115.57.46] helo=ylpvm15.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq7SV-0007g2-Uc for simple@ietf.org; Wed, 06 Jul 2005 06:48:55 -0400 Received: from pimout6-ext.prodigy.net (pimout6-int.prodigy.net [207.115.4.22]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j66ALD59002655 for ; Wed, 6 Jul 2005 06:21:13 -0400 X-ORBL: [70.249.148.178] Received: from [192.168.0.101] (ppp-70-249-148-178.dsl.rcsntx.swbell.net [70.249.148.178]) by pimout6-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with ESMTP id j66AKkWt491600; Wed, 6 Jul 2005 06:20:55 -0400 Message-ID: <42CBB090.5030500@nostrum.com> Date: Wed, 06 Jul 2005 05:21:04 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> <42CB6B82.6010403@nostrum.com> <21836729687ea7c75767c7b49617b2e5@ekabal.com> In-Reply-To: <21836729687ea7c75767c7b49617b2e5@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > MSRP authentication is used to fetch a forwarding URI that is supposed > to remain secret. The provisions that prevent against open relays > depend on trusting all the nodes on your "side" and verifying that the > other side provided one of the secret URIs you provided. I think the fallacy here is that you're viewing "trust" as an all-or-nothing proposition. It's not; otherwise, there would be no objection to requiring the use of your Social Security number, date of birth, current mailing address, and the number and date of expiration of a major credit card in the authentication requests. There's a huge gulf between trusting a relay to route messages to and from my current location on my behalf for the duration of a session without divulging the information necessary to perform such routing and trusting a relay to not divulge my password which changes on a semi-annual basis (if that frequently). > I'll point out that Jabber does not support arbitrary intermediaries > and they are successfully deploying in plenty of banks, hospitals, and > all the other regulated environments that have been cited as use cases. So define the SDP syntax necessary to set up Jabber sessions and be done with it. Or did we go down this path because we thought we could do better? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 07:19:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7wb-00007R-8j; Wed, 06 Jul 2005 07:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq7ue-0006ao-4n for simple@megatron.ietf.org; Wed, 06 Jul 2005 07:17:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01102 for ; Wed, 6 Jul 2005 07:16:08 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq84d-0001D3-TQ for simple@ietf.org; Wed, 06 Jul 2005 07:28:17 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IJ70032JCM2MX@dns2.cselt.it> for simple@ietf.org; Wed, 06 Jul 2005 12:46:50 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 06 Jul 2005 12:58:39 +0200 Date: Wed, 06 Jul 2005 13:00:08 +0200 From: Fusco Antonio To: simple@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Importance: normal Priority: normal Thread-Topic: RPID element position thread-index: AcWCGeCUPLWxKW2kQMKU0tRez1gXWw== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 06 Jul 2005 10:58:39.0875 (UTC) FILETIME=[AAA65D30:01C58219] X-Spam-Score: 0.3 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [Simple] RPID element position 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="===============1958660004==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1958660004== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C58219.DF7A2121" Content-transfer-encoding: 7bit Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C58219.DF7A2121 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 I think there's an inconsistency between PDM-02 and RPID-07 drafts: while in RPID-05 the element is used within , in the last draft it is used within (in the example at page 22).=20 Is it ok? And if it's ok, do we need a element in the presence data model? =20 Thanks,=20 Tony =20 ________________________________________________ Antonio Fusco Telecom Italia S.p.A. TILAB - StarSIP C-based platform (SeaSIP), StarSIP Java-based platform, StarSIP SCE Service and Platform Innovation - Service Control Platforms Via Reiss Romoli 274 I-10148 Torino (Italy) Tel. +39 011 228 5124 E-mail mailto:antonio.fusco@tilab.com ________________________ Visit us @ http://starsip.telecomitalialab.com =20 =20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C58219.DF7A2121 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I think there’s an inconsistency between PDM-02 = and RPID-07 drafts: while in RPID-05 the <activities> element is used = within <person><status>, in the last draft it is used within = <person> (in the example at page 22).

Is it ok? And if it’s ok, do we need a = <status> element in the presence data model?

 

Thanks,

Tony

 

________________________________________________

Antonio Fusco

Telecom Italia S.p.A.

TILAB - StarSIP C-based platform (SeaSIP), StarSIP Java-based platform, StarSIP SCE

Service and Platform Innovation - Service Control = Platforms

Via Reiss Romoli 274

I-10148 Torino (Italy)

Tel. +39 011 228 5124

E-mail mailto:antonio.fusco@tilab.com

________________________

Visit us @ http://starsip.telecomitali= alab.com

 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom = Italia = S.p.A.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= CONFIDENTIALITY NOTICE
This message and its attachments are addressed = solely to the persons
above and may contain confidential information. = If you have received
the message in error, be informed that any use = of the content hereof
is prohibited. Please return it immediately to = the sender and delete
the message. Should you have any questions, = please send an e_mail to
MailAdmin@tilab.com. Thank = you
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C58219.DF7A2121-- --===============1958660004== 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 --===============1958660004==-- From simple-bounces@ietf.org Wed Jul 06 07:32:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq88K-00032q-BB; Wed, 06 Jul 2005 07:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq87z-0002gO-E5 for simple@megatron.ietf.org; Wed, 06 Jul 2005 07:31:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03026 for ; Wed, 6 Jul 2005 07:31:41 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq8Wp-00055m-Oh for simple@ietf.org; Wed, 06 Jul 2005 07:57:26 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Jul 2005 04:29:22 -0700 X-IronPort-AV: i="3.93,264,1115017200"; d="scan'208"; a="291136984:sNHT78292752" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j66BTGod003649; Wed, 6 Jul 2005 04:29:16 -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); Wed, 6 Jul 2005 07:29:20 -0400 Received: from [192.168.1.102] ([10.86.240.200]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Jul 2005 07:29:20 -0400 Message-ID: <42CBC08F.3020905@cisco.com> Date: Wed, 06 Jul 2005 07:29:19 -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: Fusco Antonio Subject: Re: [Simple] RPID element position References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 06 Jul 2005 11:29:20.0416 (UTC) FILETIME=[F3B2A200:01C5821D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA03026 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This inconsistency is a result of me having not yet updated the PDM=20 document. has been a never-ending source of confusion, in terms=20 of determining whether an element is a status (in which case it goes in=20 there) or not (in which case it doesnt). As such, the idea was to remove=20 the status element within person and device, so everything is underneath=20 person and device directly. That will be reflected in the PDM revision=20 coming shortly. Thanks, Jonathan R. Fusco Antonio wrote: > Hi, >=20 > I think there=92s an inconsistency between PDM-02 and RPID-07 drafts:=20 > while in RPID-05 the element is used within=20 > , in the last draft it is used within (in the=20 > example at page 22). >=20 > Is it ok? And if it=92s ok, do we need a element in the presen= ce=20 > data model? >=20 > =20 >=20 > Thanks, >=20 > Tony >=20 > =20 >=20 > ________________________________________________ >=20 > Antonio Fusco >=20 > Telecom Italia S.p.A. >=20 > TILAB - StarSIP C-based platform (SeaSIP), StarSIP Java-based platform,= =20 > StarSIP SCE >=20 > Service and Platform Innovation - Service Control Platforms >=20 > Via Reiss Romoli 274 >=20 > I-10148 Torino (Italy) >=20 > Tel. +39 011 228 5124 >=20 > E-mail _mailto:antonio.fusco@tilab.com_ >=20 > ________________________ >=20 > Visit us @ http://starsip.telecomitalialab.com=20 > >=20 > =20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p= .A. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Wed Jul 06 09:14:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9ji-0007Fl-GO; Wed, 06 Jul 2005 09:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq9jg-0007CC-3s for simple@megatron.ietf.org; Wed, 06 Jul 2005 09:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18332 for ; Wed, 6 Jul 2005 09:14:39 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqA0J-0001lI-Sc for simple@ietf.org; Wed, 06 Jul 2005 09:31:57 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j66D3na6093918 for ; Wed, 6 Jul 2005 13:03:49 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j66D3mi8158144 for ; Wed, 6 Jul 2005 15:03:48 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j66D3map026576 for ; Wed, 6 Jul 2005 15:03:48 +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/8.12.11) with ESMTP id j66D3mnQ026573 for ; Wed, 6 Jul 2005 15:03:48 +0200 To: Simple WG MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Wed, 6 Jul 2005 16:03:46 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 06/07/2005 16:03:48, Serialize complete at 06/07/2005 16:03:48 X-Spam-Score: 2.6 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Simple] Expiration of partial publish 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="===============0119675757==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0119675757== Content-Type: text/html; charset="US-ASCII"
draft-ietf-simple-partial-publish-02 does not relate to the expiration of the
partial publish or at least I could not see it.
Is the intention is that each partial publish will have its own expiration and
the server will undo the partial publish when it expires?

It may be quite complex. The server may need to roll back to a previous full
or partial publish is that publish have not expired yet.
It is not like an expiration of a full publish where we can just delete the
whole element.

Avshalom
--===============0119675757== 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 --===============0119675757==-- From simple-bounces@ietf.org Wed Jul 06 10:39:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqB3z-0000dX-0a; Wed, 06 Jul 2005 10:39:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqB3u-0000aQ-VJ for simple@megatron.ietf.org; Wed, 06 Jul 2005 10:39:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04692 for ; Wed, 6 Jul 2005 10:39:37 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqBHQ-0000go-1h for simple@ietf.org; Wed, 06 Jul 2005 10:53:41 -0400 Received: from [172.17.2.244] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j66ENPin069348 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 6 Jul 2005 09:23:26 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <21836729687ea7c75767c7b49617b2e5@ekabal.com> References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> <42CB6B82.6010403@nostrum.com> <21836729687ea7c75767c7b49617b2e5@ekabal.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <76077AD0-1AFC-4281-8472-C80366590226@nostrum.com> From: Ben Campbell Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Wed, 6 Jul 2005 09:23:24 -0500 To: Rohan Mahy X-Mailer: Apple Mail (2.730) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Cullen Jennings , Avshalom Houri , Orit Levin , 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="===============0161509621==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============0161509621== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-120-618684493; protocol="application/pkcs7-signature" --Apple-Mail-120-618684493 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Jul 6, 2005, at 12:57 AM, Rohan Mahy wrote: > I'll point out that Jabber does not support arbitrary > intermediaries and they are successfully deploying in plenty of > banks, hospitals, and all the other regulated environments that > have been cited as use cases. It is not the support of arbitrary intermediaries that is being argued here. We are arguing about a potential security issue that is created by the support of arbitrary intermediaries. That's why I argued that we should either fix the password leaking issue, or we should disallow arbitrary chains of relays. But, to your point, there are certainly a lot of successful jabber deployments. There are also a lot of areas where deployment will fail. Can you describe how jabber would work in Adam's scenario? --Apple-Mail-120-618684493 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGRTCCAv4w ggJnoAMCAQICAw3JSzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwMTExMjEyMzM5WhcNMDYwMTExMjEyMzM5WjBiMR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMR4wHAYJKoZIhvcNAQkBFg9iZW5Abm9zdHJ1bS5jb20x HzAdBgkqhkiG9w0BCQEWEGJlbkBlc3RhY2Fkby5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCYWVM6KNDeP+5DdLWTRbBVLIVb4X4Yj6oYnbcNEPIRBuRGH8emhWbrCEBkDHaMQOEz izK6QEYjpoKcdmHLtKBWTMgzR/4danDoOjOeGfJ4fu9t1eXFsiVEyzf/ofZGhOzVR4q3ZfrotgjK kCTdrHpUBsyYRtRN5ZnBpxnkjVjJ77SAZ+JcSK+bs1dpohnRO6WL5ocfQXyMDzoUbnXDi1sUByd9 rCEa92lYpLKgEyr+7lkL3N56XofDV5Xzz9Y2+4GXKbTOjnN/RyNB3YDiXNB8DRclyiCvJINOFzjk 5R8AaGFs4lLoR3eZoAtidH0gp8DD1a+IEmHegjuRAmnVDqszAgMBAAGjPjA8MCwGA1UdEQQlMCOB D2JlbkBub3N0cnVtLmNvbYEQYmVuQGVzdGFjYWRvLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBACeJLe5lF2j4KsJLID+zX3t1TZvqhHqDrlpOL3ODVxK6ocXQE+bZwJX2bAhPm1Hb K8wMeeUK19VrqDnqoLzowtP+0hOjYV6CWf40OxdnjODcuSAqYsbmBBSkyRr6bQjzmqPCspJ70Dty AQ278NgOdlplxD0UJTfYKb0IPNUtuI3WMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMNyUswCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwNzA2MTQyMzI1WjAjBgkqhkiG9w0BCQQxFgQUZPP3ELK+mVY8SCsJNFvb2VZJ zxoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAw3JSzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMNyUswDQYJKoZIhvcNAQEBBQAEggEAfuNLJ73m3au/HVNlg4ZI0d3u yIV91Md/pDNBb8L3FpdP0DKbbj9hVG5Sks9BsQM2/Ts52P88tgVB9aUfUz3hjeeAap1MgOEPCFyx vs/ZZDtiULqg1sUGl6Q5Nt11b2HhTzyHegnQfO2J3796TE8EGJb5I0kh9HahtbKE5VS0hFa9HAVY +23I6kDAJgLBWAfe8gIA/erhnIKEvltacUtc4ZfGDx4FzSvB05mXF6bOSJJwA9kumLRJJ9PvX9yD tX5WdSMxORraRkKM7BlhpF9Lq5KwLkgQmb+4n4bGU9yC9Z6XXmLioqVaYB5DhMqzxjD5/6OXVBfz K1KUIr70xBestwAAAAAAAA== --Apple-Mail-120-618684493-- --===============0161509621== 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 --===============0161509621==-- From simple-bounces@ietf.org Wed Jul 06 10:55:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBIj-0003tH-Oz; Wed, 06 Jul 2005 10:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBIh-0003s9-DU for simple@megatron.ietf.org; Wed, 06 Jul 2005 10:55:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05767 for ; Wed, 6 Jul 2005 10:54:56 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqBiR-0007xv-Ei for simple@ietf.org; Wed, 06 Jul 2005 11:21:36 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j66ErU132069; Wed, 6 Jul 2005 07:53:30 -0700 In-Reply-To: <42CBB090.5030500@nostrum.com> References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> <42CB6B82.6010403@nostrum.com> <21836729687ea7c75767c7b49617b2e5@ekabal.com> <42CBB090.5030500@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8df3fe213c602a84b45f91055e0bfbf4@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Wed, 6 Jul 2005 07:52:44 -0700 To: Adam Roach X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , Avshalom Houri , "simple@ietf.org" , Rohan Mahy 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 6, 2005, at 3:21, Adam Roach wrote: > Rohan Mahy wrote: > >> MSRP authentication is used to fetch a forwarding URI that is >> supposed to remain secret. The provisions that prevent against open >> relays depend on trusting all the nodes on your "side" and verifying >> that the other side provided one of the secret URIs you provided. > > I think the fallacy here is that you're viewing "trust" as an > all-or-nothing proposition. It's not; otherwise, there would be no > objection to requiring the use of your Social Security number, date of > birth, current mailing address, and the number and date of expiration > of a major credit card in the authentication requests. > > There's a huge gulf between trusting a relay to route messages to and > from my current location on my behalf for the duration of a session > without divulging the information necessary to perform such routing > and trusting a relay to not divulge my password which changes on a > semi-annual basis (if that frequently). So you are OK with forgery, spam, and session hijacking as long as you don't have to provide your credit card number, etc...? There is text in the relay document right now that describes the process for authorizing an AUTH request. If you think you can send text that credibly (not perfectly) defines new authorization language for this section and a threat model and security considerations that addresses spam, open relays, DoS, forgery, and session hijacking then more power to you. If you think you can do that, then please send text, preferably in xml2rfc format. >> I'll point out that Jabber does not support arbitrary intermediaries >> and they are successfully deploying in plenty of banks, hospitals, >> and all the other regulated environments that have been cited as use >> cases. > > So define the SDP syntax necessary to set up Jabber sessions and be > done with it. Or did we go down this path because we thought we could > do better? I recall that we went down this path because some people said it would only take a month or two to define this protocol. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 11:11:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBZ7-0000iH-JC; Wed, 06 Jul 2005 11:11:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqBZ4-0000gp-Jk for simple@megatron.ietf.org; Wed, 06 Jul 2005 11:11:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08201 for ; Wed, 6 Jul 2005 11:11:50 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqBmk-0000q0-Vp for simple@ietf.org; Wed, 06 Jul 2005 11:26:04 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j66Evv132100; Wed, 6 Jul 2005 07:57:58 -0700 In-Reply-To: <76077AD0-1AFC-4281-8472-C80366590226@nostrum.com> References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> <42CB6B82.6010403@nostrum.com> <21836729687ea7c75767c7b49617b2e5@ekabal.com> <76077AD0-1AFC-4281-8472-C80366590226@nostrum.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2d2d7cb65a7e9b3c1d1ca39df121b08b@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension Date: Wed, 6 Jul 2005 07:57:58 -0700 To: Ben Campbell X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , Avshalom Houri , "simple@ietf.org" , Adam Roach 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 6, 2005, at 7:23, Ben Campbell wrote: > > On Jul 6, 2005, at 12:57 AM, Rohan Mahy wrote: > >> I'll point out that Jabber does not support arbitrary intermediaries >> and they are successfully deploying in plenty of banks, hospitals, >> and all the other regulated environments that have been cited as use >> cases. > > It is not the support of arbitrary intermediaries that is being argued > here. We are arguing about a potential security issue that is created > by the support of arbitrary intermediaries. That's why I argued that > we should either fix the password leaking issue, or we should disallow > arbitrary chains of relays. > > But, to your point, there are certainly a lot of successful jabber > deployments. There are also a lot of areas where deployment will fail. > Can you describe how jabber would work in Adam's scenario? Jabber won't work in Adam's scenario, but they are still successfully selling in the types of real accounts that Adam cites. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 18:02:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHyQ-0007XF-8D; Wed, 06 Jul 2005 18:02:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqHyN-0007TI-DF for simple@megatron.ietf.org; Wed, 06 Jul 2005 18:02:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02456 for ; Wed, 6 Jul 2005 18:02:24 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqIPQ-0005N1-7L for simple@ietf.org; Wed, 06 Jul 2005 18:30:25 -0400 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j66M0tP7007843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jul 2005 17:00:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <42CC5485.9030003@nostrum.com> Date: Wed, 06 Jul 2005 17:00:37 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> <2ad7b2e619d6c8bd4952aecf5f1c92b8@ekabal.com> <42CB6B82.6010403@nostrum.com> <21836729687ea7c75767c7b49617b2e5@ekabal.com> <42CBB090.5030500@nostrum.com> <8df3fe213c602a84b45f91055e0bfbf4@ekabal.com> In-Reply-To: <8df3fe213c602a84b45f91055e0bfbf4@ekabal.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > There is text in the relay document right now that describes the > process for authorizing an AUTH request. If you think you can send > text that credibly (not perfectly) defines new authorization language > for this section and a threat model and security considerations that > addresses spam, open relays, DoS, forgery, and session hijacking then > more power to you. > > If you think you can do that, then please send text, preferably in > xml2rfc format. I will endeavor to get such text together this week or early next. If I fail to do so, I'm willing to entertain moving the current draft forward with Basic authentication, given that the document includes appropriate warnings about applicability (e.g. only to be used over a single, TLS-protected hop), and that the document leaves open the option to add, at a future date, an additional authentication mechanism that can support multiple administrative domains. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 18:17:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIDE-0004N1-Qo; Wed, 06 Jul 2005 18:17:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqIDD-0004LP-9P for simple@megatron.ietf.org; Wed, 06 Jul 2005 18:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04508 for ; Wed, 6 Jul 2005 18:17:44 -0400 (EDT) Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqIeH-0008Hj-Bn for simple@ietf.org; Wed, 06 Jul 2005 18:45:45 -0400 Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id j66MHKHP027545; Wed, 6 Jul 2005 22:17:20 GMT Received: from stntexch03.cis.neustar.com ([10.31.13.45]) by stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jul 2005 18:17:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] element issue for common policy Date: Wed, 6 Jul 2005 18:17:19 -0400 Message-ID: <24EAE5D4448B9D4592C6D234CBEBD59701502FA3@stntexch03.cis.neustar.com> Thread-Topic: [Simple] element issue for common policy Thread-Index: AcWBxdWfwj/wEtspRTaixvh9m/SN3wAoe/Yg From: "Peterson, Jon" To: "Jonathan Rosenberg" , "Henning Schulzrinne" X-OriginalArrivalTime: 06 Jul 2005 22:17:20.0440 (UTC) FILETIME=[79FF7B80:01C58278] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The most compelling reason to process policies in an additive fashion is = that there may be multiple rulemakers inputting policies to the system. = External rulesets are just one example of a way that multiple distinct = entities might associate policy with a single presentity. I agree that if there is one centralized point of policy composition = then it could potentially do something sensible with this. However, I = don't think it would be behaving in an additive fashion, and it really = sounds to me like you want to have it both ways. If permissions are composed in a strictly additive fashion, then if = there are multiple rulemakers inputting policy to the point of = composition, with the addition of the more permissive policies = clobber the less permissive policies. This is scary from a privacy = perspective, and probably contrary to what many rulemakers would think = will happen. For example, if I input a rule saying that McDonalds can't = have my location information, and my service provider's default policy = is that anyone can have it, then if those are aggregated additively, = McDonald's gets my location information. This is bad, and it is a direct = result of . I can't be sure that my policies will be enforced = unless I know all of the other policies that are being inputted to the = system. When you say things like: > That experience can still be simulated with privacy safety if a web=20 > application keeps track of set of blocked users and adds them as an=20 > exception to each rule. The "web application" you're talking about is in fact a policy = compositor that doesn't follow the additive rule. There was no question = to start with that if policies weren't composed additively, then = could be made to work. However, we need to be open about our = departure from the additive model and reconsider the system accordingly. = Saying that all exceptions need to be in all domain-based rules is just = hand-waving - if there are multiple rule-makers and s are in = play, then somewhere behind it all will be a non-additive compositor. Jon Peterson NeuStar, Inc. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 06 23:55:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNUH-0007pd-82; Wed, 06 Jul 2005 23:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNUC-0007n8-Qb for simple@megatron.ietf.org; Wed, 06 Jul 2005 23:55:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01091 for ; Wed, 6 Jul 2005 23:55:38 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNvJ-00063y-5P for simple@ietf.org; Thu, 07 Jul 2005 00:23:42 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j673oYr4017754; Thu, 7 Jul 2005 06:50:34 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 06:55:27 +0300 Received: from [192.168.1.185] ([10.162.252.139]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Jul 2005 06:55:27 +0300 Message-ID: <42CCA7AE.6030501@nokia.com> Date: Thu, 07 Jul 2005 06:55:26 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Peterson, Jon" Subject: Re: [Simple] element issue for common policy References: <24EAE5D4448B9D4592C6D234CBEBD59701502FA3@stntexch03.cis.neustar.com> In-Reply-To: <24EAE5D4448B9D4592C6D234CBEBD59701502FA3@stntexch03.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 07 Jul 2005 03:55:27.0257 (UTC) FILETIME=[B5E21890:01C582A7] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext04.nokia.com id j673oYr4017754 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , simple@ietf.org, Henning Schulzrinne 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Inline. ext Peterson, Jon wrote: > The most compelling reason to process policies in an additive fashion > is that there may be multiple rulemakers inputting policies to the > system. External rulesets are just one example of a way that multiple > distinct entities might associate policy with a single presentity. >=20 > I agree that if there is one centralized point of policy composition > then it could potentially do something sensible with this. However, I > don't think it would be behaving in an additive fashion, and it > really sounds to me like you want to have it both ways. >=20 > If permissions are composed in a strictly additive fashion, then if > there are multiple rulemakers inputting policy to the point of > composition, with the addition of the more permissive > policies clobber the less permissive policies. This is scary from a > privacy perspective, and probably contrary to what many rulemakers > would think will happen. For example, if I input a rule saying that > McDonalds can't have my location information, and my service > provider's default policy is that anyone can have it, then if those > are aggregated additively, McDonald's gets my location information. > This is bad, and it is a direct result of . I can't be sure > that my policies will be enforced unless I know all of the other > policies that are being inputted to the system. How so? I can model the above with simple non-excepting rules: R1: grant "Pizza Hut", "Hesburger", "Wendy's" and "Sonic Burger"=20 location information R2: grant "any" location information How is this a direct result of ? > When you say things like: >=20 >=20 >> That experience can still be simulated with privacy safety if a web >> application keeps track of set of blocked users and adds them as >> an exception to each rule. >=20 >=20 > The "web application" you're talking about is in fact a policy > compositor that doesn't follow the additive rule. There was no > question to start with that if policies weren't composed additively, > then could be made to work. However, we need to be open > about our departure from the additive model and reconsider the system > accordingly. Saying that all exceptions need to be in all > domain-based rules is just hand-waving - if there are multiple > rule-makers and s are in play, then somewhere behind it all > will be a non-additive compositor. Forget about for a while. This is a basic feature of=20 common-policy. If there are multiple rulemakers, then there will always=20 need to be such a compositor functionality to make the overall policy=20 deterministic from the user's point of view. For example, consider a ruleset maintained by a set of rulemakers that=20 includes the following rules each created by a different rulemaker: R1: grant =C5ke, Stephen, Lisa and Carol access to presence R2: grant Alex, Bob, Billy and Chris access to presence R3: grant Atte, G=FCnther and Carol access to presence Let's say rulemaker #1 wants to remove Carol from its rule R1. It would=20 be very easy for the user to be fooled into thinking that once the grant=20 is taken away from Carol in R1, that Carol won't get presence. This of=20 course isn't so because R3 (created by rulemaker #3) also grants Carol=20 presence. *Unless* rulemaker #1 also goes through all of the other rules=20 in the ruleset, and removes all grants to Carol. Fact is, the "compositor" needs to be there between the ruleset and the=20 user, and treat the ruleset as a whole to be able to 1) present a=20 sensible representation of the policy to the user and 2) keep that=20 policy deterministic from the user's point of view. Cheers, Aki > Jon Peterson NeuStar, Inc. >=20 > _______________________________________________ Simple mailing list=20 > 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 Thu Jul 07 00:15:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNmx-0008UM-4n; Thu, 07 Jul 2005 00:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNmv-0008Tx-Am for simple@megatron.ietf.org; Thu, 07 Jul 2005 00:15:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02056 for ; Thu, 7 Jul 2005 00:14:58 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqOE0-0001PP-Cw for simple@ietf.org; Thu, 07 Jul 2005 00:43:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j674Bbro001693; Thu, 7 Jul 2005 07:11:40 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 07:14:42 +0300 Received: from [192.168.1.185] ([10.162.252.139]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Jul 2005 07:14:41 +0300 Message-ID: <42CCAC30.4020801@nokia.com> Date: Thu, 07 Jul 2005 07:14:40 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Adam Roach Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelays extension References: <75346fbbbb1cfa1a82e7f7400a959d47@ekabal.com> <07917b8077cf7036f58bb14b74f1c777@ekabal.com> <42CB5C5B.9060307@nostrum.com> In-Reply-To: <42CB5C5B.9060307@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2005 04:14:41.0803 (UTC) FILETIME=[660BD5B0:01C582AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, Since this seems to be the most detailed description of the "multiple authoritive domains" use case that I've seen yet, I'll adress it here inline. ext Adam Roach wrote: > Imagine my employer is a public company, and they have a policy of > logging all messages sent to and from my company-owned machine as a part > of Sarbanes-Oxley record keeping. Alternately, imagine I'm a securities > broker, and my company is required to log messages I send as a part of > SEC regulations. These are realistic use cases that would > administratively force me to send my messages through my company's relay. This is all understood, and my understaning is that MSRP, like email and web traffic would be sent via the same VPN to the company network, logged and only after that sent to the outside world. I'm sure many of us have done or dealt with this sort of thing for years now. > Further imagine that, in the course of business, I travel to customers' > sites from time to time. Imagine those customers allow access only > through designated proxies specific to the protocols they allow to pass. > Perhaps they allow instant message sessions, but -- as a matter of > administrative policy -- log all such inbound and outbound messages, and > consequently require the use of their MSRP relay. I'm not going to argue > that this is a reasonable thing for them to be doing; however, I can > cite two different customers that our company currently has that have > network configurations that are substantially similar to that > description (modulo the use of proprietary IM protocols). Right. I think this sort of configuration is very commonplace. > I have spent > time on their networks, and been forced to operate through their IM > relays to perform instant messaging sessions. It is unrealistic to > expect that they will change their administrative policy once MSRP is > deployed, even if you and I think it's a stupid policy. In fact, I fully > expect them to deploy MSRP relays that continue to allow them to log > instant messages as they currently are doing. The key question to ask here is: What identity are you using when working inside those companies? If you are using an external identity, why on earth would they be logging that traffic? What does Sarbanes-Oxley have that mandates logging foreign comany communication? I have a hard time buying this use case simply because I don't believe logging is necessary in two or more places at the same time. Unless this is an identity that has some serious split personality issues... > So you can say the use cases arise out of stupid regulations and stupid > administrative policies -- and I can't disagree with you. However, I > don't think it's realistic to assert that use cases involving relays in > different administrative domains actually won't arise. I believe we started with that model, so I won't disagree with you here. However, the moidel we started with included 0 to 2 relays per MSRP session, meaning that there were a maximum of two different administrative domains in play. We are now moving into a model that includes 0 to 4 or more relays per MSRP session. Meaning there are possibly four or more administrative domains involved in the MSRP session. I am concerned about this constant feature creep, especially since we are already a decade late with this work. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 07 04:15:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRXn-0008Cf-L0; Thu, 07 Jul 2005 04:15:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRXl-0008CL-6t for simple@megatron.ietf.org; Thu, 07 Jul 2005 04:15:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10691 for ; Thu, 7 Jul 2005 04:15:35 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqRyu-0006po-8Z for simple@ietf.org; Thu, 07 Jul 2005 04:43:40 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j678FWKR016107; Thu, 7 Jul 2005 11:15:33 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 11:15:32 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 11:15:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt (comments) Date: Thu, 7 Jul 2005 11:15:32 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D9DAC0B@trebe101.NOE.Nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt Thread-Index: AcUaGf1q2CxsVIaDR+eSbjE5aYOuiRopfw+A To: X-OriginalArrivalTime: 07 Jul 2005 08:15:32.0558 (UTC) FILETIME=[0B5E0EE0:01C582CC] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I'd have some (most of them just editorial) comments to the = presence-rules draft (from February) as follows. The draft is not consistent with the element; both the = and have been used. In the subsection 3.3.1.2 (person information) "" should be = replaced by "". Also, "" should be replaced = by "" in the sentence "The set combination is done = identically to the element.". The same applies also to = the corresponding sentence in the 3.3.1.3. The draft uses "the of the x instance" or "the element", = which should rather be "the of the x instance" or "the = element". The default value of the component ID (3.3.2.14) has been defined to be = "obfuscate" for the and . Basically this is correct = function from the authorization point of view, but it is unclear, which = kind of additional functionality is required from the PS and/or core = network to fulfill the "routing" requirement? (The drafts states that = the service URI must still be routable.) The Provide All Attributes (3.3.2.16) subsection lists only the = elements, which have been defined in this draft (including = the ), to belong to , = but also states in the first sentence that "all presence attributes in = all of the person etc. elements". It was a bit unclear how this should = be interpreted? Does this concern also possible future IETF and = propriotary extensions of the authorization rules providing access to = certain presence attributes or only the listed permissions? Does the = "all of person etc. elements" mean that _all_ person, device and tuple = elements are granted or only the separately "identified" person, device = and tuple elements (the identification being done by = etc.) - I'd assume that the latter one? About the in the example document: would it = be possible to change the "foo" to be a qualified element name? Thanks, Eva Leppanen > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org]On Behalf > Of ext Internet-Drafts@ietf.org > Sent: 23 February, 2005 22:59 > To: i-d-announce@ietf.org > Cc: simple@ietf.org > Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-presence > -rules-02.txt >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 07 05:28:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqSgR-0001IW-8h; Thu, 07 Jul 2005 05:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqSgP-0001Hu-6Q for simple@megatron.ietf.org; Thu, 07 Jul 2005 05:28:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15604 for ; Thu, 7 Jul 2005 05:28:34 -0400 (EDT) From: eva-maria.leppanen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqT7X-0005qP-Sm for simple@ietf.org; Thu, 07 Jul 2005 05:56:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j679PQPE011870; Thu, 7 Jul 2005 12:25:27 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 12:28:33 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 12:28:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Expiration of partial publish Date: Thu, 7 Jul 2005 12:28:31 +0300 Message-ID: <58357EDC7884E24BAD684C1B2D91F96D9DAC0D@trebe101.NOE.Nokia.com> Thread-Topic: [Simple] Expiration of partial publish Thread-Index: AcWCLjNhllLPlbKkQyi6pCZmp380EgAnv5LQ To: , X-OriginalArrivalTime: 07 Jul 2005 09:28:32.0327 (UTC) FILETIME=[3DE9C570:01C582D6] X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Avshalom, The draft states that "Unless otherwise specified in this document, the = presence user agent and presence agent behavior are as defined in the Event State = Publication Extension to SIP [2]." And in the subsection "4.3 Processing of Partial Publications" it is = said that "The compositor MUST apply the partial publication operations = in sequence against its locally stored presence information." So the partial publication should function in a similar way as the = "normal" Event State Publication. If the publication published by a PUA = is not refreshed the whole publication sequence (basically meaning the = current locally stored version of it) expires.=20 BR, Eva -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf = Of ext Avshalom Houri Sent: 06 July, 2005 16:04 To: Simple WG Subject: [Simple] Expiration of partial publish draft-ietf-simple-partial-publish-02 does not relate to the expiration = of the=20 partial publish or at least I could not see it.=20 Is the intention is that each partial publish will have its own = expiration and=20 the server will undo the partial publish when it expires?=20 It may be quite complex. The server may need to roll back to a previous = full=20 or partial publish is that publish have not expired yet.=20 It is not like an expiration of a full publish where we can just delete = the=20 whole element.=20 Avshalom=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 07 06:23:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTXY-0005Zy-S1; Thu, 07 Jul 2005 06:23:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqTXW-0005Y5-Pd for simple@megatron.ietf.org; Thu, 07 Jul 2005 06:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20044 for ; Thu, 7 Jul 2005 06:23:27 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqTyf-00018a-Qc for simple@ietf.org; Thu, 07 Jul 2005 06:51:35 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j67ANJa6175454 for ; Thu, 7 Jul 2005 10:23:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j67ANJtQ161350 for ; Thu, 7 Jul 2005 12:23:19 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j67ANIbO017724 for ; Thu, 7 Jul 2005 12:23:18 +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/8.12.11) with ESMTP id j67ANILH017721; Thu, 7 Jul 2005 12:23:18 +0200 In-Reply-To: <58357EDC7884E24BAD684C1B2D91F96D9DAC0D@trebe101.NOE.Nokia.com> To: eva-maria.leppanen@nokia.com Subject: RE: [Simple] Expiration of partial publish MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_04112005NP April 11, 2005 Message-ID: From: Avshalom Houri Date: Thu, 7 Jul 2005 13:23:18 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 07/07/2005 13:23:18, Serialize complete at 07/07/2005 13:23:18 X-Spam-Score: 2.6 (++) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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="===============1474114381==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1474114381== Content-Type: text/html; charset="US-ASCII"
Hi Maria,

Thanks for the response.

So it simply means the partial publishes also contain expiration time and
that time should be processes as if it was send in a full publish.

So it may be just my misunderstanding but it may be good to add some text
clarifies this.

Avshalom




eva-maria.leppanen@nokia.com
Sent by: simple-bounces@ietf.org

07/07/2005 12:28 PM

To
Avshalom Houri/Haifa/IBM@IBMIL, <simple@ietf.org>
cc
Subject
RE: [Simple] Expiration of partial publish





Hi Avshalom,

The draft states that "Unless otherwise specified in this document, the presence user agent
  and presence agent behavior are as defined in the Event State Publication Extension to SIP [2]."

And in the subsection "4.3  Processing of Partial Publications" it is said that "The compositor MUST apply the partial publication operations in sequence against its locally stored presence information."

So the partial publication should function in a similar way as the "normal" Event State Publication. If the publication published by a PUA is not refreshed the whole publication sequence (basically meaning the current locally stored version of it) expires.

BR, Eva

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf Of ext Avshalom Houri
Sent: 06 July, 2005 16:04
To: Simple WG
Subject: [Simple] Expiration of partial publish



draft-ietf-simple-partial-publish-02 does not relate to the expiration of the
partial publish or at least I could not see it.
Is the intention is that each partial publish will have its own expiration and
the server will undo the partial publish when it expires?

It may be quite complex. The server may need to roll back to a previous full
or partial publish is that publish have not expired yet.
It is not like an expiration of a full publish where we can just delete the
whole element.

Avshalom

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple
--===============1474114381== 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 --===============1474114381==-- From simple-bounces@ietf.org Thu Jul 07 09:24:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWMa-0003Bw-6n; Thu, 07 Jul 2005 09:24:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWMX-00039C-IF for simple@megatron.ietf.org; Thu, 07 Jul 2005 09:24:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05625 for ; Thu, 7 Jul 2005 09:24:19 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqWni-0007W3-GN for simple@ietf.org; Thu, 07 Jul 2005 09:52:27 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j67DOGAx001034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 7 Jul 2005 09:24:16 -0400 (EDT) Message-ID: <42CD2CBC.9090006@cs.columbia.edu> Date: Thu, 07 Jul 2005 09:23:08 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi Subject: Re: [Simple] element issue for common policy References: <24EAE5D4448B9D4592C6D234CBEBD59701502FA3@stntexch03.cis.neustar.com> <42CCA7AE.6030501@nokia.com> In-Reply-To: <42CCA7AE.6030501@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by serrano.cc.columbia.edu id j67DOGAx001034 X-Spam-Score: 0.2 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , "ext Peterson, Jon" , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Agree with Aki. As long as we stick to atomic, position-independent=20 rules, i.e., where each rule is independent of other rules and rule=20 ordering is immaterial, there are only two possible scenarios: (A) Additive rules: Each matching rule adds permissions. Common-policy=20 follows that model. (B) Subtractive rules: Each rule removes access based on a matching set=20 of conditions. A classical black list is a good example of that, but you=20 could construct the mirror image of the common-policy rules. The additive property is not just or primarily important for multiple=20 rule makers, but rather avoids nasty "holes" during updates without=20 requiring transactions in the update mechanism. With the additive model,=20 you can edit a rule set by removing a rule, then adding a new one, while=20 being sure that in the time between the removal and the addition, you=20 won't suddenly increase your privacy exposure. (And since the update=20 mechanim can fail or even be made to fail by an adversary, this gap=20 could me more than just a few milliseconds.) Additive rules can be privacy safe in the manner that we have defined,=20 subtractive rules cannot. (Subtractive rules might still be useful,=20 although I think harder to understand for users unless they are really=20 just lists of individuals or domains that shouldn't get access.) One can also design rule systems that are "first-match", i.e., where=20 order matters. Very early on in the GEOPRIV design process, there was=20 clear consensus that having rule sets that depend on ordering were brittl= e. For the case that Jon mentioned, subtractive rules are possibly=20 attractive, although one would hope that most providers would start out=20 with least privilege, rather than giving the world unfettered access=20 that the user then has to rein in. I hope we don't have to revisit all of these discussions again, but=20 maybe some design motivation in the draft wouldn't hurt. Henning Aki Niemi wrote: >=20 > R1: grant =C5ke, Stephen, Lisa and Carol access to presence > R2: grant Alex, Bob, Billy and Chris access to presence > R3: grant Atte, G=FCnther and Carol access to presence >=20 > Let's say rulemaker #1 wants to remove Carol from its rule R1. It would= =20 > be very easy for the user to be fooled into thinking that once the gran= t=20 > is taken away from Carol in R1, that Carol won't get presence. This of=20 > course isn't so because R3 (created by rulemaker #3) also grants Carol=20 > presence. *Unless* rulemaker #1 also goes through all of the other rule= s=20 > in the ruleset, and removes all grants to Carol. >=20 > Fact is, the "compositor" needs to be there between the ruleset and the= =20 > user, and treat the ruleset as a whole to be able to 1) present a=20 > sensible representation of the policy to the user and 2) keep that=20 > policy deterministic from the user's point of view. >=20 > Cheers, > Aki >=20 >> Jon Peterson NeuStar, Inc. >> >> _______________________________________________ Simple mailing list=20 >> 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 07 15:30:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqc59-0002ht-SR; Thu, 07 Jul 2005 15:30:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqc56-0002hm-J9 for simple@megatron.ietf.org; Thu, 07 Jul 2005 15:30:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12199 for ; Thu, 7 Jul 2005 15:30:42 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqcWK-0002GJ-FY for simple@ietf.org; Thu, 07 Jul 2005 15:58:54 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 07 Jul 2005 15:30:33 -0400 X-IronPort-AV: i="3.93,270,1115006400"; d="scan'208"; a="61420874:sNHT31956256" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j67JUWVu010484; Thu, 7 Jul 2005 15:30:32 -0400 (EDT) Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Jul 2005 15:30:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelaysextension Date: Thu, 7 Jul 2005 15:30:31 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3560ECA@xmb-rtp-20b.amer.cisco.com> Thread-Topic: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelaysextension Thread-Index: AcWCquc/1Ws/Ec4lSUuNYBJ0+0JicAAfuz1Q From: "Michael Hammer \(mhammer\)" To: "Aki Niemi" , "ext Adam Roach" X-OriginalArrivalTime: 07 Jul 2005 19:30:27.0588 (UTC) FILETIME=[54494440:01C5832A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Cc: "Cullen Jennings \(fluffy\)" , Rohan Mahy , Orit Levin , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org One might also want to consider that logging information without the consent of the parties, might also constitute an illegal wiretap. Is this really the best architecture for logging? Could not the end-user client relay its messages to a log server when that is required? It would be better to have an explicit decision on that rather than automatically assuming one. Mike =20 > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Aki Niemi > Sent: Thursday, July 07, 2005 12:15 AM > To: ext Adam Roach > Cc: Cullen Jennings (fluffy); Rohan Mahy; Orit Levin;=20 > Avshalom Houri; simple@ietf.org > Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest=20 > authentication inMSRPrelaysextension >=20 > Hi, >=20 > Since this seems to be the most detailed description of the=20 > "multiple authoritive domains" use case that I've seen yet,=20 > I'll adress it here inline. >=20 > ext Adam Roach wrote: > > Imagine my employer is a public company, and they have a policy of=20 > > logging all messages sent to and from my company-owned machine as a=20 > > part of Sarbanes-Oxley record keeping. Alternately, imagine I'm a=20 > > securities broker, and my company is required to log=20 > messages I send=20 > > as a part of SEC regulations. These are realistic use cases=20 > that would=20 > > administratively force me to send my messages through my=20 > company's relay. >=20 > This is all understood, and my understaning is that MSRP,=20 > like email and web traffic would be sent via the same VPN to=20 > the company network, logged and only after that sent to the=20 > outside world. I'm sure many of us have done or dealt with=20 > this sort of thing for years now. >=20 > > Further imagine that, in the course of business, I travel=20 > to customers'=20 > > sites from time to time. Imagine those customers allow access only=20 > > through designated proxies specific to the protocols they=20 > allow to pass. > > Perhaps they allow instant message sessions, but -- as a matter of=20 > > administrative policy -- log all such inbound and outbound=20 > messages,=20 > > and consequently require the use of their MSRP relay. I'm=20 > not going to=20 > > argue that this is a reasonable thing for them to be doing;=20 > however, I=20 > > can cite two different customers that our company currently=20 > has that=20 > > have network configurations that are substantially similar to that=20 > > description (modulo the use of proprietary IM protocols). >=20 > Right. I think this sort of configuration is very commonplace. >=20 > > I have spent > > time on their networks, and been forced to operate through their IM=20 > > relays to perform instant messaging sessions. It is unrealistic to=20 > > expect that they will change their administrative policy=20 > once MSRP is=20 > > deployed, even if you and I think it's a stupid policy. In fact, I=20 > > fully expect them to deploy MSRP relays that continue to=20 > allow them to=20 > > log instant messages as they currently are doing. >=20 > The key question to ask here is: What identity are you using=20 > when working inside those companies? >=20 > If you are using an external identity, why on earth would=20 > they be logging that traffic? What does Sarbanes-Oxley have=20 > that mandates logging foreign comany communication? >=20 > I have a hard time buying this use case simply because I=20 > don't believe logging is necessary in two or more places at=20 > the same time. Unless this is an identity that has some=20 > serious split personality issues... >=20 > > So you can say the use cases arise out of stupid regulations and=20 > > stupid administrative policies -- and I can't disagree with you. =20 > > However, I don't think it's realistic to assert that use cases=20 > > involving relays in different administrative domains=20 > actually won't arise. >=20 > I believe we started with that model, so I won't disagree=20 > with you here.=20 > However, the moidel we started with included 0 to 2 relays=20 > per MSRP session, meaning that there were a maximum of two=20 > different administrative domains in play. >=20 > We are now moving into a model that includes 0 to 4 or more=20 > relays per MSRP session. Meaning there are possibly four or=20 > more administrative domains involved in the MSRP session. >=20 > I am concerned about this constant feature creep, especially=20 > since we are already a decade late with this work. >=20 > Cheers, > Aki >=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 Thu Jul 07 17:13:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqdgS-0000Vv-Ls; Thu, 07 Jul 2005 17:13:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqdgQ-0000Vq-LB for simple@megatron.ietf.org; Thu, 07 Jul 2005 17:13:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05806 for ; Thu, 7 Jul 2005 17:13:19 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqe7f-0001sK-NY for simple@ietf.org; Thu, 07 Jul 2005 17:41:32 -0400 Received: from [131.161.248.83] (open-131-161-248-83.cliq.com [131.161.248.83]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j67LD0107080; Thu, 7 Jul 2005 14:13:00 -0700 In-Reply-To: <072C5B76F7CEAB488172C6F64B30B5E3560ECA@xmb-rtp-20b.amer.cisco.com> References: <072C5B76F7CEAB488172C6F64B30B5E3560ECA@xmb-rtp-20b.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6d48b36c01e86c19579c1faa9c301861@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest authentication inMSRPrelaysextension Date: Thu, 7 Jul 2005 14:12:46 -0700 To: "Michael Hammer \(mhammer\)" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Cc: "Cullen Jennings \(fluffy\)" , Rohan Mahy , Orit Levin , Avshalom Houri , Aki Niemi , ext 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 7, 2005, at 12:30, Michael Hammer ((mhammer)) wrote: > One might also want to consider that logging information without the > consent of the parties, might also constitute an illegal wiretap. As much as I dislike foreign relays, they don't constitute wiretapping by the Raven definition. thx, -r > Is this really the best architecture for logging? Could not the > end-user client relay its messages to a log server when that is > required? It would be better to have an explicit decision on that > rather than automatically assuming one. > > Mike > > >> -----Original Message----- >> From: simple-bounces@ietf.org >> [mailto:simple-bounces@ietf.org] On Behalf Of Aki Niemi >> Sent: Thursday, July 07, 2005 12:15 AM >> To: ext Adam Roach >> Cc: Cullen Jennings (fluffy); Rohan Mahy; Orit Levin; >> Avshalom Houri; simple@ietf.org >> Subject: Re: [Simple] OPEN ISSUE: Basic vs. Digest >> authentication inMSRPrelaysextension >> >> Hi, >> >> Since this seems to be the most detailed description of the >> "multiple authoritive domains" use case that I've seen yet, >> I'll adress it here inline. >> >> ext Adam Roach wrote: >>> Imagine my employer is a public company, and they have a policy of >>> logging all messages sent to and from my company-owned machine as a >>> part of Sarbanes-Oxley record keeping. Alternately, imagine I'm a >>> securities broker, and my company is required to log >> messages I send >>> as a part of SEC regulations. These are realistic use cases >> that would >>> administratively force me to send my messages through my >> company's relay. >> >> This is all understood, and my understaning is that MSRP, >> like email and web traffic would be sent via the same VPN to >> the company network, logged and only after that sent to the >> outside world. I'm sure many of us have done or dealt with >> this sort of thing for years now. >> >>> Further imagine that, in the course of business, I travel >> to customers' >>> sites from time to time. Imagine those customers allow access only >>> through designated proxies specific to the protocols they >> allow to pass. >>> Perhaps they allow instant message sessions, but -- as a matter of >>> administrative policy -- log all such inbound and outbound >> messages, >>> and consequently require the use of their MSRP relay. I'm >> not going to >>> argue that this is a reasonable thing for them to be doing; >> however, I >>> can cite two different customers that our company currently >> has that >>> have network configurations that are substantially similar to that >>> description (modulo the use of proprietary IM protocols). >> >> Right. I think this sort of configuration is very commonplace. >> >>> I have spent >>> time on their networks, and been forced to operate through their IM >>> relays to perform instant messaging sessions. It is unrealistic to >>> expect that they will change their administrative policy >> once MSRP is >>> deployed, even if you and I think it's a stupid policy. In fact, I >>> fully expect them to deploy MSRP relays that continue to >> allow them to >>> log instant messages as they currently are doing. >> >> The key question to ask here is: What identity are you using >> when working inside those companies? >> >> If you are using an external identity, why on earth would >> they be logging that traffic? What does Sarbanes-Oxley have >> that mandates logging foreign comany communication? >> >> I have a hard time buying this use case simply because I >> don't believe logging is necessary in two or more places at >> the same time. Unless this is an identity that has some >> serious split personality issues... >> >>> So you can say the use cases arise out of stupid regulations and >>> stupid administrative policies -- and I can't disagree with you. >>> However, I don't think it's realistic to assert that use cases >>> involving relays in different administrative domains >> actually won't arise. >> >> I believe we started with that model, so I won't disagree >> with you here. >> However, the moidel we started with included 0 to 2 relays >> per MSRP session, meaning that there were a maximum of two >> different administrative domains in play. >> >> We are now moving into a model that includes 0 to 4 or more >> relays per MSRP session. Meaning there are possibly four or >> more administrative domains involved in the MSRP session. >> >> I am concerned about this constant feature creep, especially >> since we are already a decade late with this work. >> >> Cheers, >> Aki >> >> _______________________________________________ >> 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 11 14:02:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2c4-0001vw-DU; Mon, 11 Jul 2005 14:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8Nw-000382-Tf for simple@megatron.ietf.org; Sun, 03 Jul 2005 13:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19601 for ; Sun, 3 Jul 2005 13:36:01 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp8oL-0000D2-3S for simple@ietf.org; Sun, 03 Jul 2005 14:03:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 3 Jul 2005 20:31:11 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CB44B39@mail.followap.com> Thread-Topic: draft-ietf-simple-presence-rules-02 Thread-Index: AcV/9DEtQ9xNe6tMRiytKuAG+LzvVw== From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 X-Mailman-Approved-At: Mon, 11 Jul 2005 14:02:37 -0400 Cc: simple@ietf.org Subject: [Simple] draft-ietf-simple-presence-rules-02 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="===============1021626487==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1021626487== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57FF5.016F3EC0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57FF5.016F3EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In 3.3.1.2 person transformations are discussed, and there are a couple of inconsistencies or need for clarifications: =20 * is mentioned in the first paragraph, and not explained (all devices for the person?) - as is referred in the last paragraph - probably meaning the same, it need clarifications. Sample votes for . * It is referred sometimes as and sometimes as (and from the schema and similar they do not seem to be nested as sometimes is). Sample votes for * Multiple are implied as well, from previous bullet and also the text, where it is not inline with PDM. Again, it is against the sample as well. =20 Cheers, --Fridy / Followap ------_=_NextPart_001_01C57FF5.016F3EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In 3.3.1.2 person transformations are discussed, and = there are a couple of inconsistencies or need for = clarifications:

 

  • <all-devices> is mentioned in the first paragraph, and not explained (all devices = for the person?) – as <all-persons> is referred in the last = paragraph – probably meaning the same, it need clarifications. Sample votes for = <all-persons>.
  • It is referred = sometimes as <provide-persons> and sometimes as <provide-person> = (and from the schema and similar they do not seem to be nested as sometimes = is). Sample votes for <provide-person>
  • Multiple = <person> are implied as well, from previous bullet and also the text, where it = is not inline with PDM. Again, it is against the sample as = well.
 

Cheers,

--Fridy / Followap

------_=_NextPart_001_01C57FF5.016F3EC0-- --===============1021626487== 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 --===============1021626487==-- From simple-bounces@ietf.org Mon Jul 11 14:02:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2c4-0001wM-V1; Mon, 11 Jul 2005 14:02:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpPVZ-0003WJ-OI for simple@megatron.ietf.org; Mon, 04 Jul 2005 07:53:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00430 for ; Mon, 4 Jul 2005 07:53:04 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpPry-00030Z-2A for simple@ietf.org; Mon, 04 Jul 2005 08:16:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [SIMPLE][Pres-Rules] PDM and specific information transformation in draft-ietf-simple-presence-rules-02 Date: Mon, 4 Jul 2005 14:40:54 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CB44D02@mail.followap.com> Thread-Topic: [SIMPLE][Pres-Rules] PDM and specific information transformation in draft-ietf-simple-presence-rules-02 Thread-Index: AcV/9DEtQ9xNe6tMRiytKuAG+LzvVwAAy42w From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 X-Mailman-Approved-At: Mon, 11 Jul 2005 14:02:38 -0400 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="===============1769930139==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1769930139== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5808D.E81CA1B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5808D.E81CA1B5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 How (and if) it is possible to allow a watcher to see some presence = attribute on one PDM section (e.g. person) but not in another, without = harming the other presence attributes visibility? It seems that allowing = each of the sections (tuple / person / device) in one "layer" of = transformations, and allowing the specific attributes in another layer, = is not sufficient for this scenario.=20 =20 Are these limitations acceptable? =20 Sample: presentity has in some service with additional = attributes, and also a for the . He wants to authorize = the note for the person and not for the service, for a particular = watcher. =20 The na=EFve solution of trying to use provide-person and provide-note, = but not provide-service would achieve the result "shallowly" for note, = but prevent the other service presence information. =20 Same kind (but different) problem occurs on allowing some PA for one = service but not for the other service (and again for devices). =20 What are your thoughts on this? Perhaps I am missing something... =20 --Fridy / Followap ------_=_NextPart_001_01C5808D.E81CA1B5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

How (and if) it is possible to = allow a watcher to see some presence attribute on one PDM section (e.g. person) = but not in another, without harming the other presence attributes visibility? It = seems that allowing each of the sections (tuple / person / device) in one “layer” of transformations, and allowing the specific = attributes in another layer, is not sufficient for this scenario. =

 

Are these limitations = acceptable?

 

Sample: presentity has <note> in some service <tuple> = with additional attributes, and also a <note> for the <person>. = He wants to authorize the note for the person and not for the service, for a = particular watcher.

 

The na=EFve solution of trying to = use provide-person and provide-note, but not provide-service would achieve = the result “shallowly” for note, but prevent the other service = presence information.

 

Same kind (but different) problem = occurs on allowing some PA for one service but not for the other service (and = again for devices).

 

What are your thoughts on this? = Perhaps I am missing something…

 

--Fridy / = Followap

------_=_NextPart_001_01C5808D.E81CA1B5-- --===============1769930139== 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 --===============1769930139==-- From simple-bounces@ietf.org Mon Jul 11 21:43:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds9oN-00041a-Rp; Mon, 11 Jul 2005 21:43:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds9oL-00041S-Hf for simple@megatron.ietf.org; Mon, 11 Jul 2005 21:43:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14672 for ; Mon, 11 Jul 2005 21:43:47 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsAGR-00053m-OX for simple@ietf.org; Mon, 11 Jul 2005 22:12:52 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6C1hiFX014471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 11 Jul 2005 21:43:45 -0400 (EDT) Message-ID: <42D3204F.3050109@cs.columbia.edu> Date: Mon, 11 Jul 2005 21:43:43 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Simple] New draft on composition 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I've put together a draft on presence composition, with the eventual goal of having a simple policy language that allows users to specify common composition operations. It elaborates on the composition section in draft-rosenberg-simple-presence-processing-model. You can find a slightly updated version, reflecting some private comments, at http://www.cs.columbia.edu/sip/draft/composition/draft-schulzrinne-simple-composition-00a.html One can make composition infinitely complicated, coming up with all kinds of special cases, but I don't think it is productive to go after these with a composition policy language. Thus, I'm trying to identify common operations and conditions that are likely to be amenable to something short of JavaScript operating on a DOM. There are a number of open issues; in particular, the composition of capabilities is likely to be tricky. Comments are most appreciated. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 12 15:50:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQll-0007tq-8A; Tue, 12 Jul 2005 15:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlY-0007n1-Ap; Tue, 12 Jul 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28253; Tue, 12 Jul 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRDn-0003uZ-DG; Tue, 12 Jul 2005 16:19:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsQlW-0000RN-2r; Tue, 12 Jul 2005 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: Tue, 12 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-pres-policy-caps-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Representation for Expressing Presence Policy Capabilities Author(s) : J. Rosenberg Filename : draft-ietf-simple-pres-policy-caps-00.txt Pages : 9 Date : 2005-7-12 An important component of presence services is policy. Policy systems allow the presentity to grant access to specific pieces of information to specific watchers. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines a set of Extensible Markup Language (XML) elements for expressing presence policy capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-policy-caps-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-pres-policy-caps-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-pres-policy-caps-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. --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: <2005-7-12105337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-pres-policy-caps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-pres-policy-caps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12105337.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 12 15:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlv-0007xo-Da; Tue, 12 Jul 2005 15:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQlY-0007nI-P8; Tue, 12 Jul 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28261; Tue, 12 Jul 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRDn-0003ug-R3; Tue, 12 Jul 2005 16:19:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsQlW-0000Rk-6h; Tue, 12 Jul 2005 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: Tue, 12 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-common-policy-caps-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Representation for Expressing Policy Capabilities Author(s) : J. Rosenberg Filename : draft-ietf-simple-common-policy-caps-00.txt Pages : 14 Date : 2005-7-12 An important component of presence and location services is policy. Policy systems allow the presentity or location target to grant access to specific pieces of information to specific watchers or requestors. These policy systems can be extremely simple, allowing a user to accept or block requests based solely on the identity of the requestor, to extremely complex, allowing for time based rules that grant or deny specific pieces of information. Policy systems often support vendor proprietary features. To allow for interoperability between clients which set such policies, and servers which execute them, it is necessary for clients to be able to determine the capabilities of the server to which it is connected. This specification defines an Extensible Markup Language (XML) based format for expressing such capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-common-policy-caps-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-common-policy-caps-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-common-policy-caps-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. --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: <2005-7-12105954.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-common-policy-caps-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-common-policy-caps-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-12105954.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 Wed Jul 13 11:43:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjOm-0004ad-7j; Wed, 13 Jul 2005 11:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjOk-0004YW-BF for simple@megatron.ietf.org; Wed, 13 Jul 2005 11:43:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25256 for ; Wed, 13 Jul 2005 11:43:44 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsjrA-0008F3-CZ for simple@ietf.org; Wed, 13 Jul 2005 12:13:09 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6DFhdOn013493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 13 Jul 2005 11:43:40 -0400 (EDT) Message-ID: <42D53698.6060309@cs.columbia.edu> Date: Wed, 13 Jul 2005 11:43:20 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Simple] Reminder: last day for WG last call for RPID and kin 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Today is the last day for the (2nd) WGLC for the RPID, timed-status and CIPID set of documents. I intent to submit updated versions incorporating the editorial bug fixes received mostly privately later this week, to avoid running afoul of the I-D deadline. Any last-minute comments are appreciated. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Jul 13 22:23:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DstNm-0007Zg-Hm; Wed, 13 Jul 2005 22:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DstNk-0007Z6-62; Wed, 13 Jul 2005 22:23:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02998; Wed, 13 Jul 2005 22:23:22 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DstqF-0002tc-Ui; Wed, 13 Jul 2005 22:52:53 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6E2NKbB028806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Jul 2005 22:23:21 -0400 (EDT) Message-ID: <42D5CC97.9010605@cs.columbia.edu> Date: Wed, 13 Jul 2005 22:23:19 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org, GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] PIDF-LO and the presence data 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org There doesn't seem to be any real specification indicating how exactly PIDF-LO and the SIMPLE presence data model interact. draft-ietf-geopriv-pidf-lo-03 just gives an example, putting it in within . From the perspective of the data model, that's probably the least-liekly place - tuples represent services and seem the least related to one one location, compared to devices (presumably always have exactly one location) and persons (one true location, despite attempts by people to be in two places at the same time). If a user has multiple service (tuples), it seems odd to have one random one indicate a location, or, worse, two conflicting ones. RFC 4079 describes general architecture, not really protocol bits. So far, the Data Model draft doesn't mention PIDF-LO. Did I miss a precise specification anywhere? Maybe the data model should address this; I'm also happy to add this to RPID, but that seems more of a stretch. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 00:01:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsuuD-0002Zs-M5; Thu, 14 Jul 2005 00:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsuuB-0002Ut-PQ for simple@megatron.ietf.org; Thu, 14 Jul 2005 00:00:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08044 for ; Thu, 14 Jul 2005 00:00:57 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsvMi-0005W1-MA for simple@ietf.org; Thu, 14 Jul 2005 00:30:29 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40kdq009392; Thu, 14 Jul 2005 13:00:46 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40kUa014964; Thu, 14 Jul 2005 13:00:46 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40jsi014955; Thu, 14 Jul 2005 13:00:45 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40jQn022350; Thu, 14 Jul 2005 13:00:45 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40jwB022347; Thu, 14 Jul 2005 13:00:45 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40j9X014178; Thu, 14 Jul 2005 13:00:45 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40idO005425; Thu, 14 Jul 2005 13:00:44 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j6E40iGo005422; Thu, 14 Jul 2005 13:00:44 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id NAA09523; Thu, 14 Jul 2005 13:00:41 +0900 (JST) From: Kumiko Ono To: simple@ietf.org Date: Thu, 14 Jul 2005 00:00:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 4.14 (WinNT,501) Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: kumiko@cs.columbia.edu, Henning Schulzrinne Subject: [Simple] New draft on trust_path_discovery 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi all, Henning and I wrote up the I-D that proposes a mechanism to find friends -of-friends and trusted domains, which could be used as a tool to protect users from spam/spit. We could not find any WG that this draft should belong to, but we believe the SIPPING/SIMPLE WG might be interested in this draft. Any comments are welcome. > Title : Trust Path Discovery > Author(s) : K. Ono, H. Schulzrinne > Filename : draft-ono-trust-path-discovery-00.txt > Pages : 14 > Date : 2005-7-12 > > Chained or transitive trust can be used to determine whether incoming > communication is likely to be desirable or not. We can build a > chained trust relationship by introducing friends to out friends, for > example. We propose mechanisms for discovering trust paths and > binary responsive trustworthiness. The trust paths are based on a > chain of trust relationships between users, a user and a domain, and > domains. We apply this model to relatively low-value trust > establishment, suitable for deciding whether to accept communication > requests such as emails, calls, or instant messages from strangers. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ono-trust-path-discovery-00.txt Thanks, Kumiko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 02:19:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsx41-0004HD-11; Thu, 14 Jul 2005 02:19:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsx3z-0004Gn-9R for simple@megatron.ietf.org; Thu, 14 Jul 2005 02:19:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04556 for ; Thu, 14 Jul 2005 02:19:14 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsxWW-0001Vq-M0 for simple@ietf.org; Thu, 14 Jul 2005 02:48:46 -0400 Received: from [131.161.248.87] (open-131-161-248-87.cliq.com [131.161.248.87]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j6E6J3110610; Wed, 13 Jul 2005 23:19:03 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Wed, 13 Jul 2005 23:18:53 -0700 To: "simple@ietf.org WG" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Simple] updated doc on resource-list management via WebDAV 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, Clearly we are moving forward with XCAP, however several folks asked me to update my draft on WebDAV for managing resource-lists for folks that want to migrate to locking eventually. Until the draft appears in the archives, it is available here: https://scm.sipfoundry.org/rep/ietf-drafts/rohan/xcapalt/draft-mahy- simple-xcap-alternative-01.html https://scm.sipfoundry.org/rep/ietf-drafts/rohan/xcapalt/draft-mahy- simple-xcap-alternative-01.txt thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 04:02:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyfQ-0002vQ-LK; Thu, 14 Jul 2005 04:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyfN-0002sC-An for simple@megatron.ietf.org; Thu, 14 Jul 2005 04:01:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15420 for ; Thu, 14 Jul 2005 04:01:55 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsz7u-0005UR-UZ for simple@ietf.org; Thu, 14 Jul 2005 04:31:29 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6E81W3e005845; Thu, 14 Jul 2005 03:01:33 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 14 Jul 2005 10:01:31 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155063EE279@nl0006exch001u.nl.lucent.com> From: "Brok, Jacco (Jacco)" To: "'simple@ietf.org'" Subject: RE: [Simple] PIDF-LO and the presence data model Date: Thu, 14 Jul 2005 10:01:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'Henning Schulzrinne' 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I would prefer to allow it both under device and under person, but not tuple. Justification for device: when the location is mesured by device equipment, such as GPS, Wi-Fi etc. Mostly relevant for PUBLISH. Interestingly, a user may have multiple devices which are likely not at the same location. Justification for person: when the location comes from manual input by the user, and of course when device belongs to the presentity. Mostly revelant for SUBSCRIBE/NOTIFY. Regards, Jacco -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf Of Henning Schulzrinne Sent: donderdag 14 juli 2005 4:23 To: simple@ietf.org; GEOPRIV Subject: [Simple] PIDF-LO and the presence data model There doesn't seem to be any real specification indicating how exactly PIDF-LO and the SIMPLE presence data model interact. draft-ietf-geopriv-pidf-lo-03 just gives an example, putting it in within . From the perspective of the data model, that's probably the least-liekly place - tuples represent services and seem the least related to one one location, compared to devices (presumably always have exactly one location) and persons (one true location, despite attempts by people to be in two places at the same time). If a user has multiple service (tuples), it seems odd to have one random one indicate a location, or, worse, two conflicting ones. RFC 4079 describes general architecture, not really protocol bits. So far, the Data Model draft doesn't mention PIDF-LO. Did I miss a precise specification anywhere? Maybe the data model should address this; I'm also happy to add this to RPID, but that seems more of a stretch. Henning _______________________________________________ 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 14 04:27:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsz4F-0008UB-6A; Thu, 14 Jul 2005 04:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsz4C-0008U3-TO for simple@megatron.ietf.org; Thu, 14 Jul 2005 04:27:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17075 for ; Thu, 14 Jul 2005 04:27:35 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DszWl-0006VS-Pe for simple@ietf.org; Thu, 14 Jul 2005 04:57:09 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6E8RHX6018841; Thu, 14 Jul 2005 03:27:18 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 14 Jul 2005 10:27:13 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155063EE27A@nl0006exch001u.nl.lucent.com> From: "Brok, Jacco (Jacco)" To: "'Fridy Sharon-Fridman'" Date: Thu, 14 Jul 2005 10:27:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "'simple@ietf.org'" Subject: [Simple] RE: draft-brok-simple-regulate-publish 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, So far, there has not been much interest in this I-D. This is surprising given that SIMPLE and SIPPING don't offer an adequate solution for regulating the number of presence-related messages over an expensive, narrow-band mobile channel. Protocol level solutions for throttling help, but not as much as this draft. I indend to create a new revision as soon as the RPID and PDM work is settling down. Needles to day I will update the examples according to the latest I-Ds. Regarding your MIME type question, you drew the right conclusion. At first, I thought of a different filter format for the SUBSCRIBE body. Due to the similarities with the NOTIFY body, I figured that reuse is better (too many document formats in this world already). Section 4.2 also says that the SUBSCRIBE body as defined in the draft SHOULD be used, but there MAY be others in future. Hope this helps, Jacco -----Original Message----- From: Fridy Sharon-Fridman [mailto:Fridy.Sharon-Fridman@followap.com] Sent: woensdag 13 juli 2005 15:06 To: brok@lucent.com Cc: simple@ietf.org Subject: draft-brok-simple-regulate-publish Hi, What is the status of interest of SIMPLE in this I/D? Do you plan a revision? The MIME type of an event package, usually defines the NOTIFY body, and in presence - the PUBLISH body as well. For the SUBSCRIBE body, it is usually defined to be a filtering request and is NOT having the same structure as the information above. In 4.2, it seems you try to re-use the same MIME (by adding a limitation " should be ignored by the server"). This practice seems not to fit the other event packages defined, and also creates ambiguity what exactly the MIME corresponds to. Did you specify this for simplicity? Cheers, --Fridy / Followap _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 09:51:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt47P-0002Zv-R8; Thu, 14 Jul 2005 09:51:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt47O-0002Zj-Pe for simple@megatron.ietf.org; Thu, 14 Jul 2005 09:51:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09633 for ; Thu, 14 Jul 2005 09:51:13 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4Zs-0001vQ-Pr for simple@ietf.org; Thu, 14 Jul 2005 10:20:49 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id DBF25194454 for ; Thu, 14 Jul 2005 15:50:48 +0200 (CEST) Received: from [192.168.1.56] ([192.168.1.56]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 15:55:56 +0200 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: "simple@ietf.org WG" From: Hisham Khartabil Date: Thu, 14 Jul 2005 15:50:53 +0200 X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 14 Jul 2005 13:55:56.0609 (UTC) FILETIME=[C1F12B10:01C5887B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Simple] Agenda Requests, IETF 63 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org In IETF 63, the SIMPLE WG has been allocated 1 session. The session is 2.5 hours long. The WG chairs are now collecting requests for presentation slots. Please send your request to myself and Robert along with the draft you will be presenting and the duration required. We would like to ask you to please do so no later than Friday 22nd July. Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 13:41:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt7hv-0007Ac-Hf; Thu, 14 Jul 2005 13:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt7hu-0007AX-8i for simple@megatron.ietf.org; Thu, 14 Jul 2005 13:41:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02900 for ; Thu, 14 Jul 2005 13:41:07 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt8AW-0003qI-2H for simple@ietf.org; Thu, 14 Jul 2005 14:10:47 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j6EHf3On004902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jul 2005 13:41:04 -0400 (EDT) Message-ID: <42D6A3AA.3050908@cs.columbia.edu> Date: Thu, 14 Jul 2005 13:40:58 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brok, Jacco (Jacco)" Subject: Re: [Simple] PIDF-LO and the presence data model References: <7D5D48D2CAA3D84C813F5B154F43B155063EE279@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155063EE279@nl0006exch001u.nl.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This agrees with my suggestion below, I believe. I'd like to add a wrinkle: there are cases when location information isn't directly related to a communication device. For example, we locally use RFID (user-activated swipe) and UWB (badges) to determine indoor location. These would not be devices you'd include in a presence document. There doesn't seem to be much disagreement (yet), but we do need a spec home for this before everybody does it their own way. Brok, Jacco (Jacco) wrote: > Hi, > > I would prefer to allow it both under device and under person, but not tuple. > > Justification for device: when the location is mesured by device equipment, > such as GPS, Wi-Fi etc. Mostly relevant for PUBLISH. Interestingly, a user > may have multiple devices which are likely not at the same location. > > Justification for person: when the location comes from manual input by the > user, and of course when device belongs to the presentity. Mostly revelant > for SUBSCRIBE/NOTIFY. > > Regards, > Jacco > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 18:17:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtC13-000398-4r; Thu, 14 Jul 2005 18:17:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtC11-00037O-5y for simple@megatron.ietf.org; Thu, 14 Jul 2005 18:17:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12380 for ; Thu, 14 Jul 2005 18:17:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtCTh-0004Ew-3G for simple@ietf.org; Thu, 14 Jul 2005 18:46:50 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 14 Jul 2005 15:17:00 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6EMGtod012337; Thu, 14 Jul 2005 15:16:55 -0700 (PDT) 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.211); Thu, 14 Jul 2005 18:16:59 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Jul 2005 18:16:58 -0400 Message-ID: <42D6E45A.1000608@cisco.com> Date: Thu, 14 Jul 2005 18:16:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] PIDF-LO and the presence data model References: <7D5D48D2CAA3D84C813F5B154F43B155063EE279@nl0006exch001u.nl.lucent.com> <42D6A3AA.3050908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2005 22:16:58.0723 (UTC) FILETIME=[C05BBB30:01C588C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Henning Schulzrinne wrote: > This agrees with my suggestion below, I believe. I'd like to add a > wrinkle: there are cases when location information isn't directly > related to a communication device. For example, we locally use RFID > (user-activated swipe) and UWB (badges) to determine indoor location. > These would not be devices you'd include in a presence document. They may be stupid devices, but these are still devices in my book. When this basic raw information is being published to a Presence server that will be doing composition, I think it is quite right for the incoming presence document containing a entitity containing the PIDF-LO stuff, together with perhaps a small amount of stuff indicating that this is indeed the kind of device it is - enough to provide context for composition. The composer may well take this info, fold it into a element, and drop the element. So the may never be seen by watchers. But it is still there, in the background. Alternatively, the publisher could instead publish take that same PIDF-LO data and publish it as data. But that seems less desirable to me - it gives the composer less context to work from. If there are competing sources of location information, having the raw data of where it came from could help to decide which to trust. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 14 20:14:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtDqp-0000nV-5n; Thu, 14 Jul 2005 20:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtDqn-0000nK-CN for simple@megatron.ietf.org; Thu, 14 Jul 2005 20:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23315 for ; Thu, 14 Jul 2005 20:14:43 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtEJU-00005o-KL for simple@ietf.org; Thu, 14 Jul 2005 20:44:25 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6F0Efpl006175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jul 2005 20:14:42 -0400 (EDT) Message-ID: <42D6FFEE.1060109@cs.columbia.edu> Date: Thu, 14 Jul 2005 20:14:38 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] PIDF-LO and the presence data model References: <7D5D48D2CAA3D84C813F5B154F43B155063EE279@nl0006exch001u.nl.lucent.com> <42D6A3AA.3050908@cs.columbia.edu> <42D6E45A.1000608@cisco.com> In-Reply-To: <42D6E45A.1000608@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Paul Kyzivat wrote: > They may be stupid devices, but these are still devices in my book. When > this basic raw information is being published to a Presence server that > will be doing composition, I think it is quite right for the incoming > presence document containing a entitity containing the PIDF-LO [snip] This requires at least some adjustment in the presence data model, since devices are said there to support services. Here, there would be "dangling" devices, with no service pointing to them. I don't think this is a major issue, but probably worth clearing up. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 15 11:28:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS7N-0006ug-L1; Fri, 15 Jul 2005 11:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS7M-0006ub-BU for simple@megatron.ietf.org; Fri, 15 Jul 2005 11:28:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18667 for ; Fri, 15 Jul 2005 11:28:45 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtSaB-0005wl-9A for simple@ietf.org; Fri, 15 Jul 2005 11:58:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6FFNQPW000359; Fri, 15 Jul 2005 18:23:26 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 18:28:43 +0300 Received: from [172.21.35.179] ([172.21.35.179]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Jul 2005 18:28:43 +0300 Message-ID: <42D7D62A.8020702@nokia.com> Date: Fri, 15 Jul 2005 18:28:42 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Fridy Sharon-Fridman Subject: Re: [Simple] draft-ietf-simple-partial-publish-02 - MIME Error References: <8E5AB0A04458904BB9B079055261033CA8E8D5@mail.followap.com> In-Reply-To: <8E5AB0A04458904BB9B079055261033CA8E8D5@mail.followap.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2005 15:28:43.0072 (UTC) FILETIME=[E239C400:01C58951] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: eva-maria.leppanen@nokia.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Corrected in the new revision. Cheers, Aki ext Fridy Sharon-Fridman wrote: > Hi Aki, > > > > 'application/pidf-partial+xml' has been changed to > 'application/pidf-diff+xml' throughout the document, but not in 3.2 (p .4). > > > > Cheers, > > --Fridy / Followap > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 15 11:29:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS7Y-0006vM-E8; Fri, 15 Jul 2005 11:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS7X-0006vH-12 for simple@megatron.ietf.org; Fri, 15 Jul 2005 11:28:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18673 for ; Fri, 15 Jul 2005 11:28:56 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtSaL-0005wz-SH for simple@ietf.org; Fri, 15 Jul 2005 11:58:47 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6FFStul025506; Fri, 15 Jul 2005 18:28:55 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 18:28:54 +0300 Received: from [172.21.35.179] ([172.21.35.179]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 15 Jul 2005 18:28:53 +0300 Message-ID: <42D7D635.7080802@nokia.com> Date: Fri, 15 Jul 2005 18:28:53 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Avshalom Houri Subject: Re: [Simple] Expiration of partial publish References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2005 15:28:53.0947 (UTC) FILETIME=[E8B528B0:01C58951] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7bit Cc: eva-maria.leppanen@nokia.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Correct. I've added some text that clarifies this in the new revision of the partial-publish draft. Thanks, Aki ext Avshalom Houri wrote: > > Hi Maria, > > Thanks for the response. > > So it simply means the partial publishes also contain expiration time and > that time should be processes as if it was send in a full publish. > > So it may be just my misunderstanding but it may be good to add some text > clarifies this. > > Avshalom > > > > > *eva-maria.leppanen@nokia.com* > Sent by: simple-bounces@ietf.org > > 07/07/2005 12:28 PM > > > To > Avshalom Houri/Haifa/IBM@IBMIL, > cc > > Subject > RE: [Simple] Expiration of partial publish > > > > > > > > > Hi Avshalom, > > The draft states that "Unless otherwise specified in this document, the > presence user agent > and presence agent behavior are as defined in the Event State > Publication Extension to SIP [2]." > > And in the subsection "4.3 Processing of Partial Publications" it is > said that "The compositor MUST apply the partial publication operations > in sequence against its locally stored presence information." > > So the partial publication should function in a similar way as the > "normal" Event State Publication. If the publication published by a PUA > is not refreshed the whole publication sequence (basically meaning the > current locally stored version of it) expires. > > BR, Eva > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]On Behalf > Of ext Avshalom Houri > Sent: 06 July, 2005 16:04 > To: Simple WG > Subject: [Simple] Expiration of partial publish > > > > draft-ietf-simple-partial-publish-02 does not relate to the expiration > of the > partial publish or at least I could not see it. > Is the intention is that each partial publish will have its own > expiration and > the server will undo the partial publish when it expires? > > It may be quite complex. The server may need to roll back to a previous > full > or partial publish is that publish have not expired yet. > It is not like an expiration of a full publish where we can just delete the > whole element. > > Avshalom > > _______________________________________________ > 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 Sat Jul 16 19:27:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtw41-0008QY-J4; Sat, 16 Jul 2005 19:27:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtw3z-0008Mi-0j for simple@megatron.ietf.org; Sat, 16 Jul 2005 19:27:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08368 for ; Sat, 16 Jul 2005 19:27:15 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtwX5-0007IV-0s for simple@ietf.org; Sat, 16 Jul 2005 19:57:24 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6GNRF4u024831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Jul 2005 19:27:16 -0400 (EDT) Message-ID: <42D997D2.4030907@cs.columbia.edu> Date: Sat, 16 Jul 2005 19:27:14 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050712) MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [Simple] Last-call updates for rich presence documents 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org The WG last call for the document yielded only editorial changes, resulting in http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-06.txt http://www.cs.columbia.edu/sip/draft/cipid/draft-ietf-simple-cipid-06.html and http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-08.html http://www.cs.columbia.edu/sip/draft/rpid/draft-ietf-simple-rpid-08.txt (Both have just been submitted to the I-D editor.) There were some additions to place types and their definitions, based on inputs from other user groups, and bug fixes in the schema. I'd like to ask the working group chairs to forward the document set to the IESG and IETF last call. (I realize that there is a dependency on the presence data model draft and hope that the latter will be last-called shortly.) Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 17 23:55:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuMip-0006mD-TS; Sun, 17 Jul 2005 23:55:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuMil-0006la-Uh for simple@megatron.ietf.org; Sun, 17 Jul 2005 23:55:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15409 for ; Sun, 17 Jul 2005 23:55:09 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuNC7-00053z-Tf for simple@ietf.org; Mon, 18 Jul 2005 00:25:32 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2005 20:55:02 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211-2.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6I3sxvM004146; Sun, 17 Jul 2005 20:55:00 -0700 (PDT) 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.211); Sun, 17 Jul 2005 23:54:59 -0400 Received: from [192.168.1.102] ([10.86.242.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Jul 2005 23:54:58 -0400 Message-ID: <42DB2812.1020001@cisco.com> Date: Sun, 17 Jul 2005 23:54:58 -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: Henning Schulzrinne Subject: Re: [Simple] PIDF-LO and the presence data model References: <7D5D48D2CAA3D84C813F5B154F43B155063EE279@nl0006exch001u.nl.lucent.com> <42D6A3AA.3050908@cs.columbia.edu> In-Reply-To: <42D6A3AA.3050908@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 03:54:59.0038 (UTC) FILETIME=[779B77E0:01C58B4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I think two things are needed here. Firstly, the data model should make vague reference to how location information is sensible as an example of a characteristic of a person or device. Thats it. Next, a spec needs to be formally written which does something akin to RPID but for pidf-lo, and defines how it gets used in the presence data model. This would properly define the pidf-lo elements as valid children of person and device, and discuss any other considerations around its usage with the data model, if any. Probably it can be a short draft. However, I am cautious about feature creep in either the data model or rpid, and I don't think the details of the usage of pidf-lo in the data model belong in either. -Jonathan R. Henning Schulzrinne wrote: > This agrees with my suggestion below, I believe. I'd like to add a > wrinkle: there are cases when location information isn't directly > related to a communication device. For example, we locally use RFID > (user-activated swipe) and UWB (badges) to determine indoor location. > These would not be devices you'd include in a presence document. > > There doesn't seem to be much disagreement (yet), but we do need a spec > home for this before everybody does it their own way. > > Brok, Jacco (Jacco) wrote: > >> Hi, >> >> I would prefer to allow it both under device and under person, but not >> tuple. >> >> Justification for device: when the location is mesured by device >> equipment, >> such as GPS, Wi-Fi etc. Mostly relevant for PUBLISH. Interestingly, a >> user >> may have multiple devices which are likely not at the same location. >> >> Justification for person: when the location comes from manual input by >> the >> user, and of course when device belongs to the presentity. Mostly >> revelant >> for SUBSCRIBE/NOTIFY. >> >> Regards, >> Jacco >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 18 00:46:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuNWb-0006yb-CF; Mon, 18 Jul 2005 00:46:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuNWZ-0006yS-8p for simple@megatron.ietf.org; Mon, 18 Jul 2005 00:46:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17890 for ; Mon, 18 Jul 2005 00:46:36 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuNzu-0007q8-KZ for simple@ietf.org; Mon, 18 Jul 2005 01:17:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 17 Jul 2005 21:46:26 -0700 X-IronPort-AV: i="3.93,296,1115017200"; d="scan'208"; a="198838405:sNHT30086312" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6I4kPod015558; Sun, 17 Jul 2005 21:46:25 -0700 (PDT) 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.211); Mon, 18 Jul 2005 00:46:24 -0400 Received: from [192.168.1.102] ([10.86.242.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 00:46:24 -0400 Message-ID: <42DB341F.3030304@cisco.com> Date: Mon, 18 Jul 2005 00:46:23 -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: Francois Audet Subject: Re: [Simple] tel as device identifier References: <1ECE0EB50388174790F9694F77522CCF02ECE4DB@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF02ECE4DB@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 04:46:24.0491 (UTC) FILETIME=[A6AE3BB0:01C58B53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: 'Cullen Jennings' , "'simple@ietf.org'" , 'Henning Schulzrinne' 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I never got a chance to reply to this thread when it happened, but I wanted to indicate what the data model is going to say about this. tel URI is not going to be discussed as a device identifier. At the last ietf, we did agree that we would (continue) to have UUID as a device identifer, but have it be a valid one that therefore contains a time component. This means that it is temporally persistent (once created) and unique, but not that useful as a correlator with other information about the device. Oh well. The draft will say that better ones will come along in the future. -Jonathan R. Francois Audet wrote: > Yeah, I agree with Cullen. > > Tel is definitively not a device identifier. Even in most old > traditional PBXs, you > have a device identifier that is used internally for that purpose. > > There are hunt group numbers, 800 numbers, portable numbers, and with > SIP now, my telephone > numbers rings a whole bunch of different devices. > > It is anything but a device identifier, and the trend is intensifying. > > > > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings > > Sent: Tuesday, June 21, 2005 11:31 > > To: Henning Schulzrinne; simple@ietf.org > > Subject: Re: [Simple] tel as device identifier > > > > > > > > tel is definitely not a unique device identifier - i have > > many devices with the same tel. Why not just use an UUID URN > > as a device id. > > > > > > > > > > On 6/18/05 9:42 AM, "Henning Schulzrinne" wrote: > > > > > Currently, there is no really good device identifier > > (device-id), as > > > none of the obvious candidates (IMSI, MAC address, etc) > > currently have > > > a URN definition. In order to speed deployment, one quick-and-easy > > > suggestion is to use the tel URL. While this does not > > always identify > > > a single device, in many practical cases of interest, it does. > > > Examples where this is likely to work reasonably well > > include mobile > > > phones and residential analog phones (i.e., without ENUM). > > > > > > Comments? > > > > > > Henning > > > > > > _______________________________________________ > > > 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 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 18 04:27:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQyR-0005Qb-K1; Mon, 18 Jul 2005 04:27:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQyP-0005QR-IG for simple@megatron.ietf.org; Mon, 18 Jul 2005 04:27:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21925 for ; Mon, 18 Jul 2005 04:27:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuRRn-0005aB-Sd for simple@ietf.org; Mon, 18 Jul 2005 04:58:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 18 Jul 2005 04:27:29 -0400 X-IronPort-AV: i="3.93,296,1115006400"; d="scan'208"; a="62794306:sNHT26575288" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6I8RSk6018258 for ; Mon, 18 Jul 2005 04:27:28 -0400 (EDT) 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.211); Mon, 18 Jul 2005 04:27:28 -0400 Received: from [192.168.1.102] ([10.86.242.53]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 04:27:28 -0400 Message-ID: <42DB67F0.2000609@cisco.com> Date: Mon, 18 Jul 2005 04:27: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: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 08:27:28.0418 (UTC) FILETIME=[8898E020:01C58B72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Subject: [Simple] updated data model 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Folks, I've just posted an update to the presence data model. This update reflects conclusions from last meeting, discussions since then, and results from the schema alignment activity. Until the draft appears in the archives, you can pick it up from: http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-03.txt Changes: * updated schema, consistent with rpid-07 [validated by XML Spy 2005 Rel 3] * mention that documents created MUST be valid, but entites that receive them aren't expected to validate them, and SHOULD be prepared to expect invalid ones * IANA registrations for namespace and two schemas * the element was removed from and because there was no clear line between a status and characteristic, and allowing presence attributes to appear in two different places seemed like a recipe for interoperability problems. The data model draft still talks about both status and characteristics, but a section has been added that indicates that this distinction is conceptual and only useful as an aid for understanding * added a section that discusses the interpretation of a lack of a presence attribute - follows the rfc3840 model, where it means you cant draw a conclusion. Similarly, the draft recommends including as many presence attributes as possible. * changed from the term "instance" to "occurrence" to avoid confusion with gruu. As a result, each occurence of a person, device or ID is said to have a unique occurence id. * added a paragraph describing the difference between gruu instance ID and occurrence ID * updated UUID reference to RFC4412, and added a little more discussion on its usage, clarifying that future specs will provide better device ID URNs. Added discussion on MAC address as a device ID, pros and cons. * added a paragraph on how devices can have no services, and why this may still be useful * updated example, validated with rpid and prescaps * added discussion of namespaces and document extensibility -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 18 10:37:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWk4-0003F7-PS; Mon, 18 Jul 2005 10:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuWk0-0003En-5t for simple@megatron.ietf.org; Mon, 18 Jul 2005 10:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16954 for ; Mon, 18 Jul 2005 10:37:06 -0400 (EDT) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuXDQ-0005Fl-Bu for simple@ietf.org; Mon, 18 Jul 2005 11:07:33 -0400 Received: from [206.165.16.20] (host20.belle.hyatthsiagx.com [206.165.16.20]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6IEat23019206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 10:36:56 -0400 (EDT) Message-ID: <42DBBE8E.6020109@cs.columbia.edu> Date: Mon, 18 Jul 2005 10:37:02 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] updated data model draft References: <42DB67F0.2000609@cisco.com> In-Reply-To: <42DB67F0.2000609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > * the element was removed from and because > there was no clear line between a status and characteristic, and > allowing presence attributes to appear in two different places seemed > like a recipe for interoperability problems. The data model draft > still talks about both status and characteristics, but a section has > been added that indicates that this distinction is conceptual and only > useful as an aid for understanding If the concept isn't really translated into visible protocol behavior, how is this useful to an implementor? My concern is conceptual complexity - the more philosophical concepts we discuss, the longer documents get, the more confused the non-SIMPLE-in-crowd gets and the less likely we are to see deployments. > * updated UUID reference to RFC4412, and added a little more > discussion on its usage, clarifying that future specs will provide > better device ID URNs. Added discussion on MAC address as a device ID, > pros and cons. I continue to be concerned that the two most common devices today don't have an identifier story. As far as I can tell, neither (non-WiFi) cell nor landline phones can usefully generate UUIDs since they don't have MAC addresses. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 18 11:35:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXeM-0002IL-OH; Mon, 18 Jul 2005 11:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXeK-0002Gp-OX for simple@megatron.ietf.org; Mon, 18 Jul 2005 11:35:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21404 for ; Mon, 18 Jul 2005 11:35:18 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuY7l-00016A-Rt for simple@ietf.org; Mon, 18 Jul 2005 12:05:47 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 18 Jul 2005 08:35:07 -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 j6IFYx6t028116; Mon, 18 Jul 2005 08:35:05 -0700 (PDT) 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.211); Mon, 18 Jul 2005 11:34:53 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 11:34:53 -0400 Message-ID: <42DBCC1C.5050205@cisco.com> Date: Mon, 18 Jul 2005 11:34:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] updated data model draft References: <42DB67F0.2000609@cisco.com> <42DBBE8E.6020109@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 15:34:53.0111 (UTC) FILETIME=[3E067C70:01C58BAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Henning Schulzrinne wrote: >> * updated UUID reference to RFC4412, and added a little more >> discussion on its usage, clarifying that future specs will provide >> better device ID URNs. Added discussion on MAC address as a device ID, >> pros and cons. > > I continue to be concerned that the two most common devices today don't > have an identifier story. As far as I can tell, neither (non-WiFi) cell > nor landline phones can usefully generate UUIDs since they don't have > MAC addresses. I don't understand this issue. Neither of those devices are going to be reporting their own presence status - they are going to be depending on something else to report on their behalf. Whatever is reporting on their behalf can make up some device id to use for the purpose. Or is your concern that there will be multiple sources attempting to report presence status on behalf of one of these devices, and no good way to correlate those? I can't seem to retrieve RFC 4412. I think the proper number is 4122. (Is somebody becoming dyslectic?) Once upon a time I did propose that we permit an arbitrary URI as an instance-id, but this was shot down. Looking at 4122, there is provision for generating name-based UUIDs based on names in some "name space". One form that is covered by that is "Name string is a URL". So that could be used to generate a UUID from a TEL URI. However for that to work well there would have to be some canonicalization regarding how the tel uri was represented - e.g. use of separator characters. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 18 11:40:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXjO-0003b3-N2; Mon, 18 Jul 2005 11:40:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuXjN-0003ZB-VE for simple@megatron.ietf.org; Mon, 18 Jul 2005 11:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22034 for ; Mon, 18 Jul 2005 11:40:31 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuYCn-0001Tb-Qc for simple@ietf.org; Mon, 18 Jul 2005 12:11:00 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6IFaxrV029158 for ; Mon, 18 Jul 2005 18:37:04 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 18:40:26 +0300 Received: from [172.21.35.179] ([172.21.35.179]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 18 Jul 2005 18:40:26 +0300 Message-ID: <42DBCD69.9070405@nokia.com> Date: Mon, 18 Jul 2005 18:40:25 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "simple@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 15:40:26.0296 (UTC) FILETIME=[049E7B80:01C58BAF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Simple] Update to partial presence publication 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I've updated the partial publish draft, and until it pops up in the I-D directories, I've placed a copy at: http://people.nokia.net/~aki/drafts/draft-ietf-simple-partial-publish-03.txt The biggest changes are due to accomodating the updated partial PIDF format draft, as well as some smaller fixes to address feedback from the mailing list and ones sent in private, e.g., it now has an examples section. There is also a diff between the -03 and -02 versions available here: http://people.nokia.net/~aki/drafts/draft-ietf-simple-partial-publish-03-from-02.diff.html I think this draft, along with the other partial PIDF drafts are ready for WG LC. AFAIK, there are no (known) open issues. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 18 14:47:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuaeZ-0000me-Lp; Mon, 18 Jul 2005 14:47:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuaeX-0000mU-ND for simple@megatron.ietf.org; Mon, 18 Jul 2005 14:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05054 for ; Mon, 18 Jul 2005 14:47:44 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dub7z-0004C9-Ga for simple@ietf.org; Mon, 18 Jul 2005 15:18:13 -0400 Received: from [131.107.52.210] ([131.107.52.210]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6IIldf3006116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jul 2005 14:47:41 -0400 (EDT) Message-ID: <42DBF94D.6020006@cs.columbia.edu> Date: Mon, 18 Jul 2005 14:47:41 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] updated data model draft References: <42DB67F0.2000609@cisco.com> <42DBBE8E.6020109@cs.columbia.edu> <42DBCC1C.5050205@cisco.com> In-Reply-To: <42DBCC1C.5050205@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org > > I don't understand this issue. Neither of those devices are going to be > reporting their own presence status - they are going to be depending on > something else to report on their behalf. Whatever is reporting on their > behalf can make up some device id to use for the purpose. Certainly - it just would be nice to have a mechanism that minimizes collisions. > > Or is your concern that there will be multiple sources attempting to > report presence status on behalf of one of these devices, and no good > way to correlate those? Less so. Just multiple publishers for these "imported" devices (one publisher for each, but a different publisher for the landline phone and the cell phone). > > I can't seem to retrieve RFC 4412. I think the proper number is 4122. > (Is somebody becoming dyslectic?) > > Once upon a time I did propose that we permit an arbitrary URI as an > instance-id, but this was shot down. > > Looking at 4122, there is provision for generating name-based UUIDs > based on names in some "name space". One form that is covered by that > is "Name string is a URL". So that could be used to generate a UUID from > a TEL URI. However for that to work well there would have to be some > canonicalization regarding how the tel uri was represented - e.g. use of > separator characters. I think there are multiple ways to do this, but leaving this completely to the imagination of the implementor seems likely to lead to things like device:1234 or other random things that may or may not be unique. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 18 15:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubWz-0006dg-Qq; Mon, 18 Jul 2005 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubWx-0006db-ND for simple@megatron.ietf.org; Mon, 18 Jul 2005 15:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10004 for ; Mon, 18 Jul 2005 15:43:57 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duc0O-0006Kz-SM for simple@ietf.org; Mon, 18 Jul 2005 16:14:28 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 18 Jul 2005 12:43:47 -0700 Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6IJhi6p005304; Mon, 18 Jul 2005 12:43:45 -0700 (PDT) Received: from [127.0.0.1] ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 12:48:41 -0700 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 18 Jul 2005 15:43:37 -0400 From: Cullen Jennings To: "simple@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 19:48:44.0684 (UTC) FILETIME=[B4C014C0:01C58BD1] X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Adam Roach , Rohan Mahy Subject: [Simple] New version of MSRP and MSRP relay 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Until they show up, you can find them at: http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-s essions-11.html and http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-rela ys-05.html Sorry if these URL get cut up - There are also ascii versions with a .txt file extension Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 18 18:51:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueS5-0002fU-UE; Mon, 18 Jul 2005 18:51:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueR5-0002Ny-6x; Mon, 18 Jul 2005 18:50:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06998; Mon, 18 Jul 2005 18:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DueuX-0000rD-6S; Mon, 18 Jul 2005 19:20:34 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DueR0-0008Cm-D3; Mon, 18 Jul 2005 18: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: Mon, 18 Jul 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-rpid-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : RPID: Rich Presence Extensions to the Presence Information Data Format Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-simple-rpid-08.txt Pages : 39 Date : 2005-7-18 The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. That format defines a textual note, an indication of availability (open or closed) and a Universal 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-rpid-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-rpid-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-rpid-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: <2005-7-18162341.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-rpid-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-rpid-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18162341.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 18 18:51:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueS6-0002fu-N7; Mon, 18 Jul 2005 18:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueR4-0002Nc-DQ; Mon, 18 Jul 2005 18:50:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06989; Mon, 18 Jul 2005 18:50:03 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DueuX-0000rF-2f; Mon, 18 Jul 2005 19:20:34 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DueR0-0008Cr-Dz; Mon, 18 Jul 2005 18: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: Mon, 18 Jul 2005 18:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-cipid-06.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : CIPID: Contact Information in Presence Information Data Format Author(s) : H. Schulzrinne Filename : draft-ietf-simple-cipid-06.txt Pages : 10 Date : 2005-7-18 The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. The Contact Information for 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-cipid-06.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-cipid-06.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-cipid-06.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: <2005-7-18162532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-cipid-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-cipid-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18162532.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 18 18:51:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueSb-0002mV-7J; Mon, 18 Jul 2005 18:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DueR7-0002PV-VY; Mon, 18 Jul 2005 18:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07035; Mon, 18 Jul 2005 18:50:06 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DueuX-0000rf-Mp; Mon, 18 Jul 2005 19:20:35 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DueR1-0008EX-2e; Mon, 18 Jul 2005 18:50:03 -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, 18 Jul 2005 18:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-msrp-relays-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Relay Extensions for the Message Sessions Relay Protocol (MSRP) Author(s) : C. Jennings, et al. Filename : draft-ietf-simple-msrp-relays-05.txt Pages : 36 Date : 2005-7-18 The SIMPLE Working Group uses two separate models for conveying instant messages. Pager-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 Sessions 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-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-msrp-relays-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-msrp-relays-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: <2005-7-18180012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-msrp-relays-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-msrp-relays-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-18180012.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 18 19:40:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufDv-0006nc-Ny; Mon, 18 Jul 2005 19:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufDu-0006mj-7m for simple@megatron.ietf.org; Mon, 18 Jul 2005 19:40:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26853 for ; Mon, 18 Jul 2005 19:40:30 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DufhO-0008Tu-59 for simple@ietf.org; Mon, 18 Jul 2005 20:11:04 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 18 Jul 2005 16:40:25 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.93,297,1115017200"; d="scan'208"; a="2381745:sNHT22128456" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6INeMk6003039; Mon, 18 Jul 2005 19:40:22 -0400 (EDT) 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.211); Mon, 18 Jul 2005 19:40:22 -0400 Received: from cisco.com ([161.44.79.130]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 19:40:22 -0400 Message-ID: <42DC3DE5.6070802@cisco.com> Date: Mon, 18 Jul 2005 19:40:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Simple] updated data model draft References: <42DB67F0.2000609@cisco.com> <42DBBE8E.6020109@cs.columbia.edu> <42DBCC1C.5050205@cisco.com> <42DBF94D.6020006@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jul 2005 23:40:22.0233 (UTC) FILETIME=[1055C490:01C58BF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Henning Schulzrinne wrote: >> >> I don't understand this issue. Neither of those devices are going to >> be reporting their own presence status - they are going to be >> depending on something else to report on their behalf. Whatever is >> reporting on their behalf can make up some device id to use for the >> purpose. > > Certainly - it just would be nice to have a mechanism that minimizes > collisions. Well, if that is the only concern then I think we can just leave it up to the applications. As long as they follow 4122 regarding construction of valid UUIDs there should be no big problem with collisions. If they can't follow the rules there I doubt more rules somewhere else will help. There needs to be a better reason to be more normative. >> Or is your concern that there will be multiple sources attempting to >> report presence status on behalf of one of these devices, and no good >> way to correlate those? > > Less so. Just multiple publishers for these "imported" devices (one > publisher for each, but a different publisher for the landline phone and > the cell phone). > >> I can't seem to retrieve RFC 4412. I think the proper number is 4122. >> (Is somebody becoming dyslectic?) >> >> Once upon a time I did propose that we permit an arbitrary URI as an >> instance-id, but this was shot down. >> >> Looking at 4122, there is provision for generating name-based UUIDs >> based on names in some "name space". One form that is covered by that >> is "Name string is a URL". So that could be used to generate a UUID >> from a TEL URI. However for that to work well there would have to be >> some canonicalization regarding how the tel uri was represented - e.g. >> use of separator characters. > > I think there are multiple ways to do this, Yes. And that is a problem if we expect multiple publishers of presence status for the same device. IF we expect that then it is worthwhile to come up with a recommendation on what do do. > but leaving this completely > to the imagination of the implementor seems likely to lead to things like > > device:1234 > > or other random things that may or may not be unique. AFAIK it isn't a valid URI unless the scheme is registered and it conforms to the syntax of that scheme. So while we can't count on people not doing the above, we can hang them out to dry when we discover they have. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 19 02:47:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dulsc-0004kY-1F; Tue, 19 Jul 2005 02:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dulsa-0004kO-Hg for simple@megatron.ietf.org; Tue, 19 Jul 2005 02:47:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14503 for ; Tue, 19 Jul 2005 02:46:59 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DumM9-0006qM-Kg for simple@ietf.org; Tue, 19 Jul 2005 03:17:34 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 18 Jul 2005 23:46:50 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6J6knod016078 for ; Mon, 18 Jul 2005 23:46:49 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 23:46:51 -0700 Received: from [172.20.100.209] ([10.21.145.128]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 23:46:50 -0700 Message-ID: <42DCA1D9.5030902@cisco.com> Date: Tue, 19 Jul 2005 02:46:49 -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: 19 Jul 2005 06:46:50.0094 (UTC) FILETIME=[A3E380E0:01C58C2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Subject: [Simple] updated xcap-diff spec 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Folks, I submitted an update to the xcap-diff spec. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-xcap-diff-01.txt The biggest change here is that, based discussion at last ietf, I separated this from patch-ops and reverted back to the previous appraoch, which represents the changes via a list of the xcap operations that took place. Other changes: * added additional motivations - namely that content indirection is less useful for xcap content, since the content-ID is not the same as the etag. * allow for addition and removal of entire documents by making the node-selector attribute of the put and delete event reports to be optional. the previous-etag is also optional. * allow for the xcap-diff document to indicate that a document has changed, and the new etags are provided, but the changes themselves are not in the document. The recipient of the xcap-diff would still need to fetch the content. This is really handy for config framework. A client PUTs an update, gets the new etag. Each client gets a NOTIFY indicating the new and old etags, but no change log. The client that did the PUT notices that it has the most recent copy already (since it did the PUT that caused the update), and is done. Others fetch the new document. * added terminology section and cleaned up terminology throughout the spec There aren't any open issues per se, except whether we want to continue with the separation of xcap-diff from the partial-publish and other drafts. I would like to do that. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Tue Jul 19 04:45:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunjH-0001pU-Rs; Tue, 19 Jul 2005 04:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunjG-0001om-7e for simple@megatron.ietf.org; Tue, 19 Jul 2005 04:45:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21035 for ; Tue, 19 Jul 2005 04:45:28 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuoCq-0002vw-8n for simple@ietf.org; Tue, 19 Jul 2005 05:16:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2005 01:45:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6J8j8Vd013595 for ; Tue, 19 Jul 2005 01:45:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:45:15 -0700 Received: from [172.20.100.209] ([10.21.145.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:45:09 -0700 Message-ID: <42DCBD97.60002@cisco.com> Date: Tue, 19 Jul 2005 04:45:11 -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: 19 Jul 2005 08:45:09.0908 (UTC) FILETIME=[2BB52540:01C58C3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: [Simple] updated presence-rules spec 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I submitted an update to the presence-rules spec. Until it appears in the archives, you can grab a copy here: http://www.jdrosen.net/papers/draft-ietf-simple-presence-rules-03.txt Changes: * terminology cleanup * alignment with common-policy-05 in terms of identities - presence rules just states how the identity value is obtained from digest, rfc3325 and sip-identity. * presence-rules was still depending on the processing model; that has been decoupled, mainly by being less specific in several places * anonymous sip requests are mapped to unauthenticated, since anonymity is not treated in common policy * fixed some bugs and inconsistencies * an issue we've always had is how to compute the value of "sphere" used in the common policy condition. The trouble is that the value of sphere is from a presence document, and computing the document requires the server to perform composition and privacy filtering, which are defined by the policy document itself. It is thus circuitous. We had been referencing the presence processing model for help here. I have decoupled these. Now, the draft goes the simple route. It takes all of the published presence documents for the presentity. If the sphere is in any of them, and everywhere it has the same value - that is the value of sphere. Otherwise, sphere is undefined. * updated schema based on latest common policy * removed component-id; this was the thing obfuscating contact addresses. THis was not sufficiently baked and would require serious cooperation between proxies and presence servers to work. So, it was removed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Tue Jul 19 04:57:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dunuo-0004RR-W4; Tue, 19 Jul 2005 04:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dunun-0004P3-36 for simple@megatron.ietf.org; Tue, 19 Jul 2005 04:57:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21643 for ; Tue, 19 Jul 2005 04:57:23 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuoOO-0003ON-9g for simple@ietf.org; Tue, 19 Jul 2005 05:28:00 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 19 Jul 2005 01:57:15 -0700 X-IronPort-AV: i="3.93,298,1115017200"; d="scan'208"; a="199133966:sNHT27853968" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6J8vCod001458; Tue, 19 Jul 2005 01:57:12 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:57:18 -0700 Received: from [172.20.100.209] ([10.21.145.128]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:57:14 -0700 Message-ID: <42DCC06A.9020002@cisco.com> Date: Tue, 19 Jul 2005 04:57:14 -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: eva-maria.leppanen@nokia.com Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-02.txt (comments) References: <58357EDC7884E24BAD684C1B2D91F96D9DAC0B@trebe101.NOE.Nokia.com> In-Reply-To: <58357EDC7884E24BAD684C1B2D91F96D9DAC0B@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2005 08:57:14.0761 (UTC) FILETIME=[DBC0EF90:01C58C3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for the comments. More inline. eva-maria.leppanen@nokia.com wrote: > Hi, > > I'd have some (most of them just editorial) comments to the > presence-rules draft (from February) as follows. > > The draft is not consistent with the element; both > the and have been used. Fixed. Should all be provide-persons. > > In the subsection 3.3.1.2 (person information) "" should > be replaced by "". Also, "" should be > replaced by "" in the sentence "The set combination > is done identically to the element.". The same > applies also to the corresponding sentence in the 3.3.1.3. All fixed. > > The draft uses "the of the x instance" or "the > element", which should rather be "the of the x > instance" or "the element". I believe this is right as written. It is referring to class, not service-class. Both are defined in rpid. > > The default value of the component ID (3.3.2.14) has been defined to > be "obfuscate" for the and . Basically this is > correct function from the authorization point of view, but it is > unclear, which kind of additional functionality is required from the > PS and/or core network to fulfill the "routing" requirement? (The > drafts states that the service URI must still be routable.) I have removed component-id, largely because its non-trivial to accomplish this. > > The Provide All Attributes (3.3.2.16) subsection lists only the > elements, which have been defined in this draft > (including the ), to belong to > , but also states in the first sentence that > "all presence attributes in all of the person etc. elements". It was > a bit unclear how this should be interpreted? Does this concern also > possible future IETF and propriotary extensions of the authorization > rules providing access to certain presence attributes or only the > listed permissions? All future ones that might be present. I've clarified thta. Does the "all of person etc. elements" mean that > _all_ person, device and tuple elements are granted or only the > separately "identified" person, device and tuple elements (the > identification being done by etc.) - I'd assume that > the latter one? The latter. Also clarified. > > About the in the example document: would > it be possible to change the "foo" to be a qualified element name? Right - fixed. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Tue Jul 19 04:59:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dunwi-0004pM-R8; Tue, 19 Jul 2005 04:59:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dunwh-0004ow-6U for simple@megatron.ietf.org; Tue, 19 Jul 2005 04:59:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21790 for ; Tue, 19 Jul 2005 04:59:21 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuoQH-0003U0-96 for simple@ietf.org; Tue, 19 Jul 2005 05:29:58 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2005 01:59:12 -0700 X-IronPort-AV: i="3.93,298,1115017200"; d="scan'208"; a="314780452:sNHT32081206" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6J8x5VZ017938; Tue, 19 Jul 2005 01:59:09 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:59:08 -0700 Received: from [172.20.100.209] ([10.21.145.128]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:59:05 -0700 Message-ID: <42DCC0D8.5080107@cisco.com> Date: Tue, 19 Jul 2005 04:59: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: Fridy Sharon-Fridman Subject: Re: [SIMPLE][Pres-Rules] PDM and specific information transformation in draft-ietf-simple-presence-rules-02 References: <8E5AB0A04458904BB9B079055261033CB44D02@mail.followap.com> In-Reply-To: <8E5AB0A04458904BB9B079055261033CB44D02@mail.followap.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 19 Jul 2005 08:59:06.0013 (UTC) FILETIME=[1E10A4D0:01C58C40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA21790 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This kind of capability had been discussed (and indeed present in=20 previous versions of the draft IIRC). However, we decided to keep things=20 simple and just provide attributes globally. It is very easy to think of=20 all different kinds of permissions and we are trying to keep the scope=20 narrow. Thanks, Jonathan R. Fridy Sharon-Fridman wrote: > Hi, >=20 > =20 >=20 > How (and if) it is possible to allow a watcher to see some presence=20 > attribute on one PDM section (e.g. person) but not in another, without=20 > harming the other presence attributes visibility? It seems that allowin= g=20 > each of the sections (tuple / person / device) in one =93layer=94 of=20 > transformations, and allowing the specific attributes in another layer,= =20 > is not sufficient for this scenario. >=20 > =20 >=20 > Are these limitations acceptable? >=20 > =20 >=20 > _Sample_: presentity has in some service with additional= =20 > attributes, and also a for the . He wants to authorize=20 > the note for the person and not for the service, for a particular watch= er. >=20 > =20 >=20 > The na=EFve solution of trying to use provide-person and provide-note, = but=20 > not provide-service would achieve the result =93shallowly=94 for note, = but=20 > prevent the other service presence information. >=20 > =20 >=20 > Same kind (but different) problem occurs on allowing some PA for one=20 > service but not for the other service (and again for devices). >=20 > =20 >=20 > What are your thoughts on this? Perhaps I am missing something=85 >=20 > =20 >=20 > --Fridy / Followap >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Tue Jul 19 04:59:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunxE-0005E0-Lr; Tue, 19 Jul 2005 04:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunxB-00057f-4X for simple@megatron.ietf.org; Tue, 19 Jul 2005 04:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21847 for ; Tue, 19 Jul 2005 04:59:51 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuoQm-0003Vu-9p for simple@ietf.org; Tue, 19 Jul 2005 05:30:28 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 19 Jul 2005 01:59:43 -0700 X-IronPort-AV: i="3.93,298,1115017200"; d="scan'208"; a="314781252:sNHT33828116" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6J8xYVd018105; Tue, 19 Jul 2005 01:59:40 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:59:38 -0700 Received: from [172.20.100.209] ([10.21.145.128]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 01:59:35 -0700 Message-ID: <42DCC0F8.2000109@cisco.com> Date: Tue, 19 Jul 2005 04:59:36 -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: Fridy Sharon-Fridman References: <8E5AB0A04458904BB9B079055261033CB44B39@mail.followap.com> In-Reply-To: <8E5AB0A04458904BB9B079055261033CB44B39@mail.followap.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 19 Jul 2005 08:59:35.0391 (UTC) FILETIME=[2F935EF0:01C58C40] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA21847 Cc: simple@ietf.org Subject: [Simple] Re: draft-ietf-simple-presence-rules-02 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for the comments. These were all bugs, all of which were also=20 reported by Eva. I've addressed them in the most recent revision of the=20 spec. Thanks, Jonathan R. Fridy Sharon-Fridman wrote: > Hi, >=20 > =20 >=20 > In 3.3.1.2 person transformations are discussed, and there are a couple= =20 > of inconsistencies or need for clarifications: >=20 > =20 >=20 > * is mentioned in the first paragraph, and not > explained (all devices for the person?) =96 as is > referred in the last paragraph =96 probably meaning the same, it > need clarifications. Sample votes for . > * It is referred sometimes as and sometimes as > (and from the schema and similar they do not see= m > to be nested as sometimes is). Sample votes for > * Multiple are implied as well, from previous bullet and > also the text, where it is not inline with PDM. Again, it is > against the sample as well. >=20 > =20 >=20 > Cheers, >=20 > --Fridy / Followap >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Wed Jul 20 10:50:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFth-0005tv-G9; Wed, 20 Jul 2005 10:50:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFta-0005rN-9Q; Wed, 20 Jul 2005 10:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23334; Wed, 20 Jul 2005 10:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvGNR-0007nR-4I; Wed, 20 Jul 2005 11:20:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvFtZ-0005tJ-Cu; Wed, 20 Jul 2005 10: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: Wed, 20 Jul 2005 10:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-03.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A Data Model for Presence Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-data-model-03.txt Pages : 34 Date : 2005-7-20 This document defines the underlying presence data model and used by Session Initiation Protocol (SIP) for Instant Messaging Leveraging Presence Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-03.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-presence-data-model-03.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-presence-data-model-03.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: <2005-7-20102937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-data-model-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-data-model-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20102937.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 Wed Jul 20 15:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKaK-00068J-Gx; Wed, 20 Jul 2005 15:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKZw-0005ty-LV; Wed, 20 Jul 2005 15:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25105; Wed, 20 Jul 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3o-0004JD-OS; Wed, 20 Jul 2005 16:20:57 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZu-0007i5-7V; Wed, 20 Jul 2005 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, 20 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-publish-03.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Publication of Partial Presence Information Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-publish-03.txt Pages : 16 Date : 2005-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-03.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-03.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-03.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: <2005-7-20111023.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-publish-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-publish-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20111023.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 Wed Jul 20 15:51:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKbc-0006i5-K9; Wed, 20 Jul 2005 15:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKa4-0005zK-Hs; Wed, 20 Jul 2005 15:50:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25198; Wed, 20 Jul 2005 15:50:10 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3q-0004KN-8g; Wed, 20 Jul 2005 16:21:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZv-0007mc-QG; Wed, 20 Jul 2005 15:50:03 -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, 20 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-xcap-diff-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : An Extensible Markup Language (XML) Document Format for Indicating Changes in XML Configuration Access Protocol (XCAP) Resources Author(s) : J. Rosenberg Filename : draft-ietf-simple-xcap-diff-01.txt Pages : 16 Date : 2005-7-20 This specification defines a document format that can be used to describe the differences between versions of resources managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP diff documents can be delivered to clients using a number of means, including the Session Initiation Protocol (SIP) event package for configuration data. By subscribing to this event package, clients can learn about document changes made by other clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-01.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-xcap-diff-01.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-xcap-diff-01.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: <2005-7-20134822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-xcap-diff-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-xcap-diff-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20134822.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 Wed Jul 20 15:52:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKbp-0006nK-6n; Wed, 20 Jul 2005 15:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKa6-000611-7W; Wed, 20 Jul 2005 15:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25216; Wed, 20 Jul 2005 15:50:12 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3q-0004Km-WA; Wed, 20 Jul 2005 16:21:04 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZw-0007oG-DD; Wed, 20 Jul 2005 15:50:04 -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, 20 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-message-sessions-11.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : The Message Session Relay Protocol Author(s) : B. Campbell, et al. Filename : draft-ietf-simple-message-sessions-11.txt Pages : 56 Date : 2005-7-20 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 setup via a rendezvous or session setup 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-11.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-11.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-11.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: <2005-7-20145055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-message-sessions-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-message-sessions-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20145055.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 Wed Jul 20 15:53:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKcn-0007NQ-Nm; Wed, 20 Jul 2005 15:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKaD-000667-KH; Wed, 20 Jul 2005 15:50:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25307; Wed, 20 Jul 2005 15:50:18 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvL3q-0004KE-6Z; Wed, 20 Jul 2005 16:21:02 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZv-0007mH-MW; Wed, 20 Jul 2005 15:50:03 -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, 20 Jul 2005 15:50:03 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-rules-03.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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Authorization Rules Author(s) : J. Rosenberg Filename : draft-ietf-simple-presence-rules-03.txt Pages : 25 Date : 2005-7-20 Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration Access Protocol (XCAP), although other techniques are permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules-03.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-presence-rules-03.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-presence-rules-03.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: <2005-7-20133850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presence-rules-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presence-rules-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20133850.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 21 10:52:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcP8-000546-Ix; Thu, 21 Jul 2005 10:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcP6-00051G-Vh for simple@megatron.ietf.org; Thu, 21 Jul 2005 10:52:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07273 for ; Thu, 21 Jul 2005 10:52:02 -0400 (EDT) Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvct5-00059D-5I for simple@ietf.org; Thu, 21 Jul 2005 11:23:05 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6LEpn8j129572 for ; Thu, 21 Jul 2005 14:51:49 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6LEpnM0177886 for ; Thu, 21 Jul 2005 16:51:49 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6LEpnIr025218 for ; Thu, 21 Jul 2005 16:51:49 +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/8.12.11) with ESMTP id j6LEpnWR025212 for ; Thu, 21 Jul 2005 16:51:49 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Avshalom Houri Message-ID: Date: Thu, 21 Jul 2005 17:51:47 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 21/07/2005 17:51:48, Serialize complete at 21/07/2005 17:51:48 X-Spam-Score: 2.3 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Simple] SIMPLE and VOIPEER meetings on the same slot 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="===============1081134146==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1081134146== Content-Type: text/html; charset="US-ASCII"
According to current Paris IETF agenda both SIMPLE group and the VOIPEER meeting
are on the same slot Thu 1400-1630. It seems that a lot of people would want to
attend both.

Avshalom

--===============1081134146== 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 --===============1081134146==-- From simple-bounces@ietf.org Thu Jul 21 12:42:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dve8F-0006c0-Gc; Thu, 21 Jul 2005 12:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dve8D-0006br-FK for simple@megatron.ietf.org; Thu, 21 Jul 2005 12:42:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16853 for ; Thu, 21 Jul 2005 12:42:42 -0400 (EDT) Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvecG-0004FL-T7 for simple@ietf.org; Thu, 21 Jul 2005 13:13:50 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id BBDA7194449 for ; Thu, 21 Jul 2005 18:42:25 +0200 (CEST) Received: from [192.168.1.38] ([192.168.1.38]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jul 2005 18:47:53 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2ced0b1665c1d4c59c46da2a8dd21cd6@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] SIMPLE and VOIPEER meetings on the same slot Date: Thu, 21 Jul 2005 18:42:24 +0200 To: Avshalom Houri X-Mailer: Apple Mail (2.622) X-OriginalArrivalTime: 21 Jul 2005 16:47:53.0465 (UTC) FILETIME=[F028B690:01C58E13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org We are aware of this. We are trying as hard as we can to eliminate this conflict. Thanks, Hisham On Jul 21, 2005, at 4:51 PM, Avshalom Houri wrote: > > According to current Paris IETF agenda both SIMPLE group and the > VOIPEER meeting > are on the same slot Thu 1400-1630. It seems that a lot of people > would want to > attend both. > > Avshalom > > _______________________________________________ > 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 21 13:57:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfIr-0000FQ-Sv; Thu, 21 Jul 2005 13:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfIq-0000EE-7S for simple@megatron.ietf.org; Thu, 21 Jul 2005 13:57:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21910 for ; Thu, 21 Jul 2005 13:57:47 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvfmu-0001DS-9k for simple@ietf.org; Thu, 21 Jul 2005 14:28:53 -0400 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j6LHvhEd005886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 12:57:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <42DFE206.6090509@nostrum.com> Date: Thu, 21 Jul 2005 12:57:26 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avshalom Houri Subject: Re: [Simple] SIMPLE and VOIPEER meetings on the same slot References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org There has been vigorous discussion of this specific issue on the working group chairs mailing list. The secretariat is doing their best to resolve conflicts; however, there may not be a viable solution to this particular scheduling problem. The root issue is the fact that work in the area of real-time communication is now being performed in a large _and_ _growing_ list of working groups: mmusic, sip, simple, sipping, xcon, avt, and iptel -- many of which end up with two slots; and that's ignoring working groups that have charter items that real-time communication relies upon, like behave, enum, ecrit, ieprep, geopriv, midcom, rohc, dnsext, aaa, netconf, radext... the list goes on. When you try to figure out how to slot in those 7 working groups -- with their 10 or so requested slots -- over a 4-and-a-half day period, it's pretty tricky. When you add in chair restraints (Cullen can't present in SIMPLE and chair BEHAVE at the same time, for example) and AD restraints (Allison can't attend SIPPING and IPS at the same time), it becomes even a more difficult problem. As far as I can tell (and this is simply my personal opinion), the only real solution is for companies who have a vested interest in helping the IETF do its work need to start investing more resources. Yes, it is annoying that one of Ben or I are going to have to miss SIMPLE so that our company has someone attending VOIPEER, but our solution is to ensure that we have enough people showing up that we can cover everything. /a Avshalom Houri wrote: > > According to current Paris IETF agenda both SIMPLE group and the > VOIPEER meeting > are on the same slot Thu 1400-1630. It seems that a lot of people > would want to > attend both. > > Avshalom > >------------------------------------------------------------------------ > >_______________________________________________ >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 21 15:56:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvhA0-000421-UC; Thu, 21 Jul 2005 15:56:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvh9z-00041m-Qc for simple@megatron.ietf.org; Thu, 21 Jul 2005 15:56:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05370 for ; Thu, 21 Jul 2005 15:56:46 -0400 (EDT) Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvhe4-0001I8-MU for simple@ietf.org; Thu, 21 Jul 2005 16:27:54 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j6LJuaYR145674 for ; Thu, 21 Jul 2005 19:56:36 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6LJuaM0143588 for ; Thu, 21 Jul 2005 21:56:36 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j6LJua7r016587 for ; Thu, 21 Jul 2005 21:56:36 +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/8.12.11) with ESMTP id j6LJuac2016584; Thu, 21 Jul 2005 21:56:36 +0200 In-Reply-To: <42DFE206.6090509@nostrum.com> To: Adam Roach , Hisham Khartabil Subject: Re: [Simple] SIMPLE and VOIPEER meetings on the same slot MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005 From: Avshalom Houri Message-ID: Date: Thu, 21 Jul 2005 22:56:34 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 21/07/2005 22:56:36, Serialize complete at 21/07/2005 22:56:36 X-Spam-Score: 2.6 (++) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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="===============1223459194==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --===============1223459194== Content-Type: text/html; charset="US-ASCII"
A possible alternative is to schedule the VOIPEER BOF on time where there are no
other meeting similar to an ad-hoc.

I am not sure if the will be according to the customs of the IETF but it may
benefit a lot of people.

Avshalom


Adam Roach <adam@nostrum.com>
Sent by: simple-bounces@ietf.org

21/07/2005 08:57 PM

To
Avshalom Houri/Haifa/IBM@IBMIL
cc
simple@ietf.org
Subject
Re: [Simple] SIMPLE and VOIPEER meetings on the same slot





There has been vigorous discussion of this specific issue on the working
group chairs mailing list. The secretariat is doing their best to
resolve conflicts; however, there may not be a viable solution to this
particular scheduling problem.

The root issue is the fact that work in the area of real-time
communication is now being performed in a large _and_ _growing_ list of
working groups: mmusic, sip, simple, sipping, xcon, avt, and iptel --
many of which end up with two slots; and that's ignoring working groups
that have charter items that real-time communication relies upon, like
behave, enum, ecrit, ieprep, geopriv, midcom, rohc, dnsext, aaa,
netconf, radext... the list goes on.

When you try to figure out how to slot in those 7 working groups -- with
their 10 or so requested slots -- over a 4-and-a-half day period, it's
pretty tricky. When you add in chair restraints (Cullen can't present in
SIMPLE and chair BEHAVE at the same time, for example) and AD restraints
(Allison can't attend SIPPING and IPS at the same time), it becomes even
a more difficult problem.

As far as I can tell (and this is simply my personal opinion), the only
real solution is for companies who have a vested interest in helping the
IETF do its work need to start investing more resources. Yes, it is
annoying that one of Ben or I are going to have to miss SIMPLE so that
our company has someone attending VOIPEER, but our solution is to ensure
that we have enough people showing up that we can cover everything.

/a

Avshalom Houri wrote:

>
> According to current Paris IETF agenda both SIMPLE group and the
> VOIPEER meeting
> are on the same slot Thu 1400-1630. It seems that a lot of people
> would want to
> attend both.
>
> Avshalom
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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
--===============1223459194== 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 --===============1223459194==-- From simple-bounces@ietf.org Fri Jul 22 07:18:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvYK-0001Ir-Au; Fri, 22 Jul 2005 07:18:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvvYI-0001Im-LX for simple@megatron.ietf.org; Fri, 22 Jul 2005 07:18:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02788 for ; Fri, 22 Jul 2005 07:18:47 -0400 (EDT) Received: from [202.177.174.130] (helo=mail.spanservices.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvw2V-0000CZ-96 for simple@ietf.org; Fri, 22 Jul 2005 07:50:05 -0400 Received: from Maya ([172.16.1.195]) by mail.spanservices.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 16:46:55 +0530 From: "Ashutosh P - SPAN" To: Date: Fri, 22 Jul 2005 16:46:55 +0530 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Importance: Normal X-OriginalArrivalTime: 22 Jul 2005 11:16:55.0858 (UTC) FILETIME=[DE841920:01C58EAE] X-Spam-Score: 0.6 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Subject: [Simple] Help required regarding Presence Server.......... 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="===============2107933222==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============2107933222== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C58EDC.F8379A30" This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C58EDC.F8379A30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, A warm HI to all the members of this list from a new member...... I am presently starting to work on the presence server stuff..... I am using the existing resiprocate stack for presence server. But before that I want some clarifications related PUBLISH method used = in presence server implemetation. I want to use PUBLISH method for publication of presence info. And SUBSCRIBE & NOTIFY for subscription to presence info. MY query is: Is it that REGISTER should be used before PUBLISH ? Or I can implement only PUBLISH for both registration and publication? Also anyone who knows anything about the above mentioned stack can help = me understand as to what exactly is implemented in relation to presence server in the stack. I shall be very thankful for any response. Thanks & Regards, Ashutosh Pattanaik. SPAN Systems Corporation, Bangalore.=20 "Steering Progress, Together"=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This email message and any attachments is confidential and=20 intended only for the use of an individual or entity named=20 above and may contain information that is privileged,=20 confidential or exempt from disclosure under applicable law.=20 If you are not the intended recipient, you are notified that=20 any dissemination, distribution or copying of this email is=20 strictly prohibited.If you have received this email in error,=20 please notify us immediately by return email or=20 itsupport@spanservices.com and destroy the original message.=20 Opinions, conclusions, and other information in this message=20 that do not relate to the official business of SPAN, shall be=20 understood to be neither given nor endorsed by SPAN. ------=_NextPart_000_0020_01C58EDC.F8379A30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
 
A warm = HI to all=20 the members of this list from a new member......
I am = presently=20 starting to work on the presence server stuff.....
I = am using the=20 existing resiprocate stack for presence = server.
But before that I want some clarifications related PUBLISH method used in=20 presence
server = implemetation.
 
I want = to use=20 PUBLISH method for publication of presence info.
And SUBSCRIBE & NOTIFY for subscription to = presence=20 info.
MY query is:
   =20 Is it that REGISTER should be used before PUBLISH ?
Or I can=20 implement only PUBLISH for both = registration and=20 publication?
 
Also=20 anyone who knows anything about=20  the above mentioned stack can help me understand as=20 to
what exactly is implemented in relation to=20 presence server in the stack.
 
I = shall be very=20 thankful for any response.
 
Thanks & = Regards,
    Ashutosh=20 Pattanaik.
 
SPAN Systems Corporation, Bangalore.=20 "Steering Progress, Together"=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This email message and any attachments is confidential and=20 intended only for the use of an individual or entity named=20 above and may contain information that is privileged,=20 confidential or exempt from disclosure under applicable law.=20 If you are not the intended recipient, you are notified that=20 any dissemination, distribution or copying of this email is=20 strictly prohibited.If you have received this email in error,=20 please notify us immediately by return email or=20 itsupport@spanservices.com and destroy the original message.=20 Opinions, conclusions, and other information in this message=20 that do not relate to the official business of SPAN, shall be=20 understood to be neither given nor endorsed by SPAN. ------=_NextPart_000_0020_01C58EDC.F8379A30-- --===============2107933222== 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 --===============2107933222==-- From simple-bounces@ietf.org Fri Jul 22 09:09:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxHB-0000Xi-IU; Fri, 22 Jul 2005 09:09:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxH6-0000Wr-QB for simple@megatron.ietf.org; Fri, 22 Jul 2005 09:09:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13302 for ; Fri, 22 Jul 2005 09:09:10 -0400 (EDT) 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 1DvxlK-0004nt-SX for simple@ietf.org; Fri, 22 Jul 2005 09:40:28 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 22 Jul 2005 06:09:02 -0700 X-IronPort-AV: i="3.95,134,1120460400"; d="scan'208"; a="650167068:sNHT29899088" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6MD91JL003766; Fri, 22 Jul 2005 06:09:01 -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); Fri, 22 Jul 2005 09:09:33 -0400 Received: from [192.168.1.100] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 09:09:10 -0400 Message-ID: <42E0EFEB.1090607@cisco.com> Date: Fri, 22 Jul 2005 09:08:59 -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: Ashutosh P - SPAN Subject: Re: [Simple] Help required regarding Presence Server.......... References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2005 13:09:10.0262 (UTC) FILETIME=[8C889960:01C58EBE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org PUBLISH doesn't replace REGISTER (though there are those who have proposed that it does, it currently does not). Thus, you need to register. -Jonathan R. Ashutosh P - SPAN wrote: > All, > > A warm HI to all the members of this list from a new member...... > I am presently starting to work on the presence server stuff..... > I am using the existing resiprocate stack for presence server. > But before that I want some clarifications related PUBLISH method used > in presence > server implemetation. > > I want to use PUBLISH method for publication of presence info. > And SUBSCRIBE & NOTIFY for subscription to presence info. > MY query is: > Is it that REGISTER should be used before PUBLISH ? > Or I can implement only PUBLISH for both registration and publication? > > Also anyone who knows anything about the above mentioned stack can help > me understand as to > what exactly is implemented in relation to presence server in the stack. > > I shall be very thankful for any response. > > Thanks & Regards, > Ashutosh Pattanaik. > > SPAN Systems Corporation, Bangalore. "Steering Progress, Together" > ============================================================= This email > message and any attachments is confidential and intended only for the > use of an individual or entity named above and may contain information > that is privileged, confidential or exempt from disclosure under > applicable law. If you are not the intended recipient, you are notified > that any dissemination, distribution or copying of this email is > strictly prohibited.If you have received this email in error, please > notify us immediately by return email or itsupport@spanservices.com and > destroy the original message. Opinions, conclusions, and other > information in this message that do not relate to the official business > of SPAN, shall be understood to be neither given nor endorsed by SPAN. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Fri Jul 22 09:36:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxhI-0004Qv-BZ; Fri, 22 Jul 2005 09:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvxhH-0004Qn-31 for simple@megatron.ietf.org; Fri, 22 Jul 2005 09:36:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14895 for ; Fri, 22 Jul 2005 09:36:13 -0400 (EDT) Received: from [202.177.174.130] (helo=mail.spanservices.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvyBW-0005n0-26 for simple@ietf.org; Fri, 22 Jul 2005 10:07:30 -0400 Received: from Maya ([172.16.1.195]) by mail.spanservices.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jul 2005 19:04:19 +0530 From: "Ashutosh P - SPAN" To: "Jonathan Rosenberg" Subject: RE: [Simple] Help required regarding Presence Server.......... Date: Fri, 22 Jul 2005 19:04:19 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <42E0EFEB.1090607@cisco.com> Importance: Normal X-OriginalArrivalTime: 22 Jul 2005 13:34:19.0999 (UTC) FILETIME=[10682EF0:01C58EC2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Jonathan, Thanks for your reply. I just want to confirm that for a presence server implemention I should use the step like... Register - for registration Publish - for presence info publication Subscribe/Notify - for subscripion of presence info of presentity. means if I am implementing these 4 methods I can have a presence server. Also can I implement authentication through Digest in PUBLISH , like it is there in Register? Please correct me if I a wrong somewhere....... Regards, -Ashutosh. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Friday, July 22, 2005 6:39 PM To: Ashutosh P - SPAN Cc: simple@ietf.org Subject: Re: [Simple] Help required regarding Presence Server.......... PUBLISH doesn't replace REGISTER (though there are those who have proposed that it does, it currently does not). Thus, you need to register. -Jonathan R. Ashutosh P - SPAN wrote: > All, > > A warm HI to all the members of this list from a new member...... > I am presently starting to work on the presence server stuff..... > I am using the existing resiprocate stack for presence server. > But before that I want some clarifications related PUBLISH method used > in presence > server implemetation. > > I want to use PUBLISH method for publication of presence info. > And SUBSCRIBE & NOTIFY for subscription to presence info. > MY query is: > Is it that REGISTER should be used before PUBLISH ? > Or I can implement only PUBLISH for both registration and publication? > > Also anyone who knows anything about the above mentioned stack can help > me understand as to > what exactly is implemented in relation to presence server in the stack. > > I shall be very thankful for any response. > > Thanks & Regards, > Ashutosh Pattanaik. > > SPAN Systems Corporation, Bangalore. "Steering Progress, Together" > ============================================================= This email > message and any attachments is confidential and intended only for the > use of an individual or entity named above and may contain information > that is privileged, confidential or exempt from disclosure under > applicable law. If you are not the intended recipient, you are notified > that any dissemination, distribution or copying of this email is > strictly prohibited.If you have received this email in error, please > notify us immediately by return email or itsupport@spanservices.com and > destroy the original message. Opinions, conclusions, and other > information in this message that do not relate to the official business > of SPAN, shall be understood to be neither given nor endorsed by SPAN. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 SPAN Systems Corporation, Bangalore. "Steering Progress, Together" ============================================================= This email message and any attachments is confidential and intended only for the use of an individual or entity named above and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited.If you have received this email in error, please notify us immediately by return email or itsupport@spanservices.com and destroy the original message. Opinions, conclusions, and other information in this message that do not relate to the official business of SPAN, shall be understood to be neither given nor endorsed by SPAN. SPAN Systems Corporation, Bangalore. "Steering Progress, Together" ============================================================= This email message and any attachments is confidential and intended only for the use of an individual or entity named above and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited.If you have received this email in error, please notify us immediately by return email or itsupport@spanservices.com and destroy the original message. Opinions, conclusions, and other information in this message that do not relate to the official business of SPAN, shall be understood to be neither given nor endorsed by SPAN. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 25 15:10:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8L8-0001bq-UX; Mon, 25 Jul 2005 15:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx8L7-0001bl-91 for simple@megatron.ietf.org; Mon, 25 Jul 2005 15:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15482 for ; Mon, 25 Jul 2005 15:10:11 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx8q0-00052Y-Df for simple@ietf.org; Mon, 25 Jul 2005 15:42:09 -0400 Received: from ATLANTIS.Brooktrout.com (oceans11.brooktrout.com [204.176.75.121]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j6PJ5JT5004261 for ; Mon, 25 Jul 2005 15:05:19 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2005 15:05:18 -0400 Message-ID: <330A23D8336C0346B5C1A5BB196666477AD88A@ATLANTIS.Brooktrout.com> Thread-Topic: IMDN Thread-Index: AcWRS8yDm9D5KomOQIuyMIOkmIFSzw== From: "Eric Burger" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Subject: [Simple] IMDN 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I posted an update to Instant Message Delivery Notification (IMDN) for Common Presence and Instant Messaging (CPIM) Messages. The broad differences from -00 are: 1. The work group seems to be enamored with XML. Instead of using MDN-style or CPIM-style keyword header - value PDU's, we use XML. Kind of silly, as you already have to have a header - value parser to use CPIM, and the extensibility isn't likely to be in the areas where XML helps. 2. The message format and transport protocol is compatible with lists (exploders), relays (MSRP), and gateways (non-CPIM, as well as to e-mail). 3. The message format and transport protocol enables the possibility for end-to-end security through list exploders and gateways. 4. Imposes a globally unique message ID on the CPIM message. While this is not strictly necessary, experience in the e-mail world shows this will become very important for message tracking. Compared to draft-khartabil-simple-im-report-00: 1. Drop the "confirm" content disposition. 2. Drop the backward message ID restrictions; message ID is orthogonal to the report. 3. Impose a MUST NOT for a IMDN to request an IMDN. 4. Identify the IMDN at the CPIM level, so you don't have to parse the whole message to figure out what it is. 5. Considerably less state burden in the gateway / list exploder case. There are a ton of open issues indicated in the draft, such as the meaning of "only report failure." I offered that makes no sense, and thus isn't a possibility. Clearly, I can put it in easily, but I would like to see a cogent argument describing what it means. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Jul 25 16:36:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9gQ-0003bR-KG; Mon, 25 Jul 2005 16:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx9gO-0003Yf-MH for simple@megatron.ietf.org; Mon, 25 Jul 2005 16:36:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21859 for ; Mon, 25 Jul 2005 16:36:15 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxABJ-0007nu-MH for simple@ietf.org; Mon, 25 Jul 2005 17:08:14 -0400 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j6PKZx7W016811; Mon, 25 Jul 2005 15:35:59 -0500 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 25 Jul 2005 15:30:05 -0500 Message-ID: From: "Nancy Greene (QC/EMC)" To: simple@ietf.org Subject: RE: [Simple] New version of MSRP and MSRP relay Date: Mon, 25 Jul 2005 15:35:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) X-Spam-Score: 0.8 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: Cullen Jennings , Rohan Mahy , Adam Roach 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="===============0283947440==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0283947440== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59158.75D86FC5" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C59158.75D86FC5 Content-Type: text/plain; charset="iso-8859-1" Hi, here are some comments on MSRP-11: - The section listing differences from previous versions has been removed. Are all differences from -10 editorial? Editorial comments: - 2nd last paragraph in section 7.1: The following text is now covered in paragraphs 3&4 in section 7.1, so the following should be deleted: " Finally, requests which have no body MUST NOT contain a Content-Type header or any other MIME specific header. Requests without bodies MUST contain a end-line after the final header." - section 7.3.2, 5th paragraph - change "when and endpoint" to "when an endpoint" Nancy -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Sent: Monday, July 18, 2005 3:44 PM To: simple@ietf.org Cc: Cullen Jennings; Adam Roach; Rohan Mahy Subject: [Simple] New version of MSRP and MSRP relay Until they show up, you can find them at: http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-message-s essions-11.html and http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple-msrp-rela ys-05.html Sorry if these URL get cut up - There are also ascii versions with a .txt file extension Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C59158.75D86FC5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New version of MSRP and MSRP relay

Hi, here are some comments on MSRP-11:

- The section listing differences from previous = versions has been removed. Are all differences from -10 editorial? =

Editorial comments:
- 2nd last paragraph in section 7.1: The following = text is now covered in paragraphs 3&4 in section 7.1, so the = following should be deleted:

"  Finally, requests which have no body = MUST NOT contain a Content-Type
   header or any other MIME specific = header.  Requests without bodies
   MUST contain a end-line after the final = header."

- section 7.3.2, 5th paragraph - change "when = and endpoint" to "when an endpoint"

Nancy

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]
Sent: Monday, July 18, 2005 3:44 PM
To: simple@ietf.org
Cc: Cullen Jennings; Adam Roach; Rohan Mahy
Subject: [Simple] New version of MSRP and MSRP relay =



Until they show up, you can find them at:

http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft= -ietf-simple-message-s
essions-11.html

and

http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft= -ietf-simple-msrp-rela
ys-05.html

Sorry if these URL get cut up - There are also ascii = versions with a .txt
file extension

Cullen


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------_=_NextPart_001_01C59158.75D86FC5-- --===============0283947440== 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 --===============0283947440==-- From simple-bounces@ietf.org Mon Jul 25 17:12:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAFV-0002cF-Bf; Mon, 25 Jul 2005 17:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAFR-0002c2-Qz for simple@megatron.ietf.org; Mon, 25 Jul 2005 17:12:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23919 for ; Mon, 25 Jul 2005 17:12:27 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAkK-0000KG-8c for simple@ietf.org; Mon, 25 Jul 2005 17:44:27 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2005 14:12:17 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="325881904:sNHT28832020" 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 j6PLCEIs013111; Mon, 25 Jul 2005 14:12:14 -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.211); Mon, 25 Jul 2005 17:12:21 -0400 Received: from [192.168.1.100] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 17:12:25 -0400 Message-ID: <42E555AF.1030202@cisco.com> Date: Mon, 25 Jul 2005 17:12:15 -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: Paul Kyzivat Subject: Re: [Simple] updated data model draft References: <42DB67F0.2000609@cisco.com> <42DBBE8E.6020109@cs.columbia.edu> <42DBCC1C.5050205@cisco.com> <42DBF94D.6020006@cs.columbia.edu> <42DC3DE5.6070802@cisco.com> In-Reply-To: <42DC3DE5.6070802@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2005 21:12:25.0673 (UTC) FILETIME=[8E627390:01C5915D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Simple WG , Henning Schulzrinne 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Paul Kyzivat wrote: > > > Henning Schulzrinne wrote: > >>> >>> I don't understand this issue. Neither of those devices are going to >>> be reporting their own presence status - they are going to be >>> depending on something else to report on their behalf. Whatever is >>> reporting on their behalf can make up some device id to use for the >>> purpose. >> >> >> Certainly - it just would be nice to have a mechanism that minimizes >> collisions. > > > Well, if that is the only concern then I think we can just leave it up > to the applications. As long as they follow 4122 regarding construction > of valid UUIDs there should be no big problem with collisions. > > If they can't follow the rules there I doubt more rules somewhere else > will help. There needs to be a better reason to be more normative. We can go a teeny step further; if, for now, we are not concerned about correlations, and all we want is uniqueness, we can recommend usage of version 4 UUID, which do not require a mac or a registered namespace. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 25 17:15:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAIK-0003Oa-Cl; Mon, 25 Jul 2005 17:15:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAIH-0003OP-P9 for simple@megatron.ietf.org; Mon, 25 Jul 2005 17:15:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24118 for ; Mon, 25 Jul 2005 17:15:23 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAnD-0000RW-63 for simple@ietf.org; Mon, 25 Jul 2005 17:47:23 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 25 Jul 2005 14:15:16 -0700 X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="200467681:sNHT30105192" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6PLET7N004855; Mon, 25 Jul 2005 14:15:13 -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.211); Mon, 25 Jul 2005 17:14:21 -0400 Received: from [192.168.1.100] ([10.86.242.189]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 17:14:15 -0400 Message-ID: <42E55627.7000706@cisco.com> Date: Mon, 25 Jul 2005 17:14:15 -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: Henning Schulzrinne Subject: Re: [Simple] updated data model draft References: <42DB67F0.2000609@cisco.com> <42DBBE8E.6020109@cs.columbia.edu> In-Reply-To: <42DBBE8E.6020109@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2005 21:14:15.0582 (UTC) FILETIME=[CFE53BE0:01C5915D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Henning Schulzrinne wrote: >> * the element was removed from and because >> there was no clear line between a status and characteristic, and >> allowing presence attributes to appear in two different places seemed >> like a recipe for interoperability problems. The data model draft >> still talks about both status and characteristics, but a section has >> been added that indicates that this distinction is conceptual and only >> useful as an aid for understanding > > > If the concept isn't really translated into visible protocol behavior, > how is this useful to an implementor? > > My concern is conceptual complexity - the more philosophical concepts we > discuss, the longer documents get, the more confused the > non-SIMPLE-in-crowd gets and the less likely we are to see deployments. Its a question of whether the discussion is helpful to aid in understanding, or not. YMMV, I suppose. It seems that there has been a lot of confusion about what presence data is and isn't, which is why the model document was written. As such, a thorough treatment of the kinds of things that might be presence, and why they are useful, is in order. Rather than lumping all such presence data into one bucket, the draft splits it out into various types. I think that aids in comprehension. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 25 17:28:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAVB-0006kt-5i; Mon, 25 Jul 2005 17:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxAV9-0006jn-0r for simple@megatron.ietf.org; Mon, 25 Jul 2005 17:28:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25160 for ; Mon, 25 Jul 2005 17:28:37 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxB00-0000tJ-75 for simple@ietf.org; Mon, 25 Jul 2005 18:00:37 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2005 14:28:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.95,140,1120460400"; d="scan'208"; a="3322367:sNHT22637568" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6PLSSVu005665; Mon, 25 Jul 2005 17:28:29 -0400 (EDT) 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.211); Mon, 25 Jul 2005 17:28:35 -0400 Received: from [192.168.1.100] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 17:28:39 -0400 Message-ID: <42E5597B.8030003@cisco.com> Date: Mon, 25 Jul 2005 17:28:27 -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: Kumiko Ono Subject: Re: [Simple] New draft on trust_path_discovery References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2005 21:28:39.0911 (UTC) FILETIME=[D3135F70:01C5915F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: kumiko@cs.columbia.edu, simple@ietf.org, Henning Schulzrinne 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a very interesting draft. This kind of presence-based reputation system is definitely a strong contender for a piece of the anti-spam puzzle. Building a protocol to do this is very challenging. One of the design decisions is whether or not it is pushed based, akin to a vector routing protocl (as you have proposed) or whether it is query-based. I am concerned that a push-based routing protocol type of solution is simply not going to scale, as the level of aggregation will not be sufficient. Though there is a form of aggregation, in terms of combining paths to the same recipient, there is no way to aggregate decisions across recipients. The latter is analagous to combining prefixes in BGP, and that is not possible here since the identifiers are from a flat namespace. Furthermore, I may not want to reveal all of my trust relationships to everyone, indeed, I may not want to reveal the same trust relationships to different people. Consider this example. I have a buddy list with lots of buddies on it. Those buddies include colleagues from work, family, and certain business associates that I deal with, but confidentially (example: the business development manager from a company about to acquire my company). I don't want everyone I trust to actually know that I trust this biz dev guy, since that reveals confidential information. Because of this, I think that these trust chains need to be query based. Indeed, care must be taken to make sure the privacy issues I mention above can be dealt with. Indeed, if you allow transitive queries - user A queries B that queries C, it can get really hard to preserve the privacy needed. Thanks, Jonathan R. Kumiko Ono wrote: > Hi all, > > Henning and I wrote up the I-D that proposes a mechanism to find friends > -of-friends and trusted domains, which could be used as a tool to > protect users from spam/spit. We could not find any WG that this draft > should belong to, but we believe the SIPPING/SIMPLE WG might be > interested in this draft. Any comments are welcome. > > > >> Title : Trust Path Discovery >> Author(s) : K. Ono, H. Schulzrinne >> Filename : draft-ono-trust-path-discovery-00.txt >> Pages : 14 >> Date : 2005-7-12 >> >> Chained or transitive trust can be used to determine whether incoming >> communication is likely to be desirable or not. We can build a >> chained trust relationship by introducing friends to out friends, for >> example. We propose mechanisms for discovering trust paths and >> binary responsive trustworthiness. The trust paths are based on a >> chain of trust relationships between users, a user and a domain, and >> domains. We apply this model to relatively low-value trust >> establishment, suitable for deciding whether to accept communication >> requests such as emails, calls, or instant messages from strangers. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ono-trust-path-discovery-00.txt > > > Thanks, > Kumiko > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 25 22:09:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEt4-00046Z-KV; Mon, 25 Jul 2005 22:09:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEt2-00046U-ME for simple@megatron.ietf.org; Mon, 25 Jul 2005 22:09:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14232 for ; Mon, 25 Jul 2005 22:09:39 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxFNz-0000wj-Ja for simple@ietf.org; Mon, 25 Jul 2005 22:41:41 -0400 Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net [141.153.198.113]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j6Q28IgG011300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jul 2005 22:08:18 -0400 (EDT) Message-ID: <42E59B17.2080808@cs.columbia.edu> Date: Mon, 25 Jul 2005 22:08:23 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] New draft on trust_path_discovery References: <42E5597B.8030003@cisco.com> In-Reply-To: <42E5597B.8030003@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: kumiko@cs.columbia.edu, Kumiko Ono , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Thanks for the comments. I agree that scaling is going to be a challenge, although one has to be careful to compare distribution with local caching with queries in terms of overall efficiency. (This is something we have not done yet, unfortunately.) Unlike BGP routing data, these trust relationships are likely to be stable over very long time periods, measured at least in days or weeks, so that the total volume of information may not be all that large, particularly if one constrains the propagation. (This is the converse to BGP aggregation - you need to advertise every prefix that can't be aggregated, even if across ten AS hops, while long-haul trust relationships are probably of little interest. A friend ten links removed is not too meaningful.) In general, if this type of trust path discovery is useful, it is likely to be useful for a somewhat enlarged group beyond one's own immediate acquaintances. I would expect to find most IETFers and networking faculty on my list of trust paths, but not a random teenager from New Zealand. Those strangers may just have to send me email first ("don't call me, I'll call you"). The problem with query-based protocols is to find the trusting parties, i.e., answering "who is trusting John Doe (who is sending me an IM)?". It would be very difficult to go ask all my friends and then have them ask their friends. As to the privacy issues, I think the only viable solution is to only declare "public" trust, i.e., for people that one is willing to stand up for in public, similar to the links in the various social network sites like Friendster. This will reduce the number of trust relationships, but for most people, I suspect that the large majority of "do I trust this person not to be selling aluminum siding" cases won't fall into the category of friends that need to be hidden from the world. This clearly needs more discussion in the draft. Henning Jonathan Rosenberg wrote: > This is a very interesting draft. This kind of presence-based reputation > system is definitely a strong contender for a piece of the anti-spam > puzzle. > > Building a protocol to do this is very challenging. One of the design > decisions is whether or not it is pushed based, akin to a vector routing > protocl (as you have proposed) or whether it is query-based. I am > concerned that a push-based routing protocol type of solution is simply > not going to scale, as the level of aggregation will not be sufficient. > Though there is a form of aggregation, in terms of combining paths to > the same recipient, there is no way to aggregate decisions across > recipients. The latter is analagous to combining prefixes in BGP, and > that is not possible here since the identifiers are from a flat namespace. > > Furthermore, I may not want to reveal all of my trust relationships to > everyone, indeed, I may not want to reveal the same trust relationships > to different people. Consider this example. I have a buddy list with > lots of buddies on it. Those buddies include colleagues from work, > family, and certain business associates that I deal with, but > confidentially (example: the business development manager from a company > about to acquire my company). I don't want everyone I trust to actually > know that I trust this biz dev guy, since that reveals confidential > information. > > Because of this, I think that these trust chains need to be query based. > Indeed, care must be taken to make sure the privacy issues I mention > above can be dealt with. Indeed, if you allow transitive queries - user > A queries B that queries C, it can get really hard to preserve the > privacy needed. > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Jul 26 17:11:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWiL-000515-MT; Tue, 26 Jul 2005 17:11:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWiI-00050I-Tw for simple@megatron.ietf.org; Tue, 26 Jul 2005 17:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24509 for ; Tue, 26 Jul 2005 17:11:44 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxXDQ-0002Ml-NH for simple@ietf.org; Tue, 26 Jul 2005 17:43:57 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 14:11:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 14:11:36 -0700 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, 26 Jul 2005 14:11:35 -0700 Message-ID: Thread-Topic: [Sipping] Inter-Domain Requirements for SIP/SIMPLE Thread-Index: AcWR3zae3zPgzAmKTt6LqgsBibwVwAAH4ThQAAMj4DAABopl8AAAPeWg From: "Orit Levin" To: X-OriginalArrivalTime: 26 Jul 2005 21:11:36.0565 (UTC) FILETIME=[9B86EA50:01C59226] X-Spam-Score: 1.3 (+) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable Subject: [Simple] FW: [Sipping] Inter-Domain Requirements for SIP/SIMPLE 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org FYI only. Let's keep this thread on SIPPING. -----Original Message----- From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf Of Orit Levin Sent: Tuesday, July 26, 2005 2:05 PM To: sipping@ietf.org Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE We (i.e. the co-authors) obviously think that the document is useful. It has served us very well as a working tool for deploying public to enterprise IM connectivity. We are still constantly referring our customers and competitors interested in this type of interconnection to it. We planned to present the draft at SIMPLE or SIPPING, but currently there are no time slots available on either. The reason for presenting the draft was to figure out the best way forward: an individual informational RFC vs. a WG BCP. In other words, we wanted to raise the exact three questions that Michael is asking below in his email. Regarding presenting the draft at the VoIP Peering BoF - the authors feel very hesitant about it. For the "profile" and the specific SIMPLE requirements talked about in this draft - there is really no need to establish a new WG. We believe that they all naturally fall under SIP and SIMPLE. It is true that Service Providers will most probably need a similar profile as a part of their connectivity but they are currently looking for a much broader scope - beyond the standard SIP/SIMPLE. Thanks, Orit. > -----Original Message----- > From: sipping-bounces@ietf.org > [mailto:sipping-bounces@ietf.org] On Behalf Of Michael Hammer > (mhammer) > Sent: Tuesday, July 26, 2005 11:03 AM > To: henry@pulver.com; rjsparks@nostrum.com; hisham.khartabil@telio.no; > sipping@ietf.org; gonzalo.camarillo@ericsson.com > Cc: hardie@qualcomm.com; Jake Salinger; sah@428cobrajet.net; Dean=20 > Willis > Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE >=20 > Henry, >=20 > I too agree that there is some good information in this document. =20 > But, my question to the group is whether that is sufficient reason for > the group to take on this *type* of work. My impression is that in=20 > the past such work was deemed out of scope. (Implementation-oriented, > "we don't do profiles", etc.) The questions that should be addressed=20 > before this > one: >=20 > 1. Will adding this to the workload delay existing WG items further? >=20 > 2. Will adding this to the workload preclude other more core protocol > work from being added as WG items and addressed in a timely fashion? >=20 > 3. How will this group deal with other fora that are doing similar=20 > work? >=20 > Perhaps the VoIP Peering BoF will also touch on the above. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Henry Sinnreich > > Sent: Tuesday, July 26, 2005 12:59 PM > > To: rjsparks@nostrum.com; hisham.khartabil@telio.no; > sipping@ietf.org; > > gonzalo.camarillo@ericsson.com > > Cc: hardie@qualcomm.com; 'Jake Salinger'; > sah@428cobrajet.net; 'Dean > > Willis' > > Subject: FW: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > >=20 > >=20 > > >It should definitely become a SIPPING WG item. This document > > is great.=20 > >=20 > > If Dean thought this request can be dismissed with a joke:=20 > We will be > > persistent. > >=20 > > Especially in view of the VoIP Peering BOF. > >=20 > > Thanks, Henry > > =20 > >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Jake Salinger > > Sent: Monday, July 25, 2005 7:30 AM > > To: sipping@ietf.org > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > >=20 > > It should definitely become a SIPPING WG item. This > document is great. > >=20 > >=20 > >=20 > >=20 > > ----- Original Message ----- > > From: > > To: "'Dean Willis'" ; > > Cc: > > Sent: Monday, July 25, 2005 4:18 PM > > Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > >=20 > >=20 > > > >Could we just poll the mailing list instead? > > > > > > > > http://www.ietf.org/internet-drafts/draft-levin-simple-interdo > > main-reqs-02.t > > > xt > > > > > > What are the opinions on this list? Should it become a > > SIPPING WG item? > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Sunday, July 24, 2005 6:50 PM > > > To: henry@pulver.com > > > Cc: sipping@ietf.org > > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > > > > > > > > > On Jul 23, 2005, at 9:53 AM, Henry Sinnreich wrote: > > > > > > > The I-D Inter-Domain Requirements for SIP/SIMPLE > > > >=20 > > http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain- > > > > reqs-02.t > > > > xt > > > > > > > > is not only a very good document but is also very timely > > for other > > > > inter-domain communications, such as between all the > > emerging VoIP > > > > islands (the islands are a regrettable fact at present). > > > > > > > > I suggest therefore having a 5 minute hum so as to make > > it a SIPPING > > > > WG item. > > > > > > > > > Henry, I'm pretty sure that if we ask the working group to > > hum for 5 > > > minutes that the resulting anoxia would preclude further > > useful work > > > for the remainder of the meeting. > > > > > > Could we just poll the mailing list instead? > > > > > > -- > > > Dean > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP Use=20 > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 28 02:49:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2Cv-0002mQ-59; Thu, 28 Jul 2005 02:49:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2Ct-0002mG-Li for simple@megatron.ietf.org; Thu, 28 Jul 2005 02:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00254 for ; Thu, 28 Jul 2005 02:49:25 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy2iH-0001Ax-TY for simple@ietf.org; Thu, 28 Jul 2005 03:21:55 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 08:46:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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, 28 Jul 2005 08:46:42 +0200 Message-ID: Thread-Topic: Comment about draft-ietf-simple-event-list-07.txt Thread-Index: AcWTQB3VZzUR/0MnTmK2pJVugW4caQ== From: "MARJOU Xavier RD-MAPS-LAN" To: X-OriginalArrivalTime: 28 Jul 2005 06:46:43.0469 (UTC) FILETIME=[1DA85BD0:01C59340] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comment about draft-ietf-simple-event-list-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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, In "Section 6 Example", the Presence document of some presentities is sent directly by the RLS in F3. This must not possible because Privacy Filtering is not executed at the RLS, but at the Presence Server of each presentity. Thus immediate answer from RLS breaks "privacy filtering" of those presentities. I think this suggested by the sentence "RLS is also an authority for presence information for the users in the vancouver.example.com domain.", but I think it is worth underlying this "privacy filtering" aspect. Xavier _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 28 12:57:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyBgy-0000QB-7B; Thu, 28 Jul 2005 12:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyBgw-0000Q6-GM for simple@megatron.ietf.org; Thu, 28 Jul 2005 12:57:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12510 for ; Thu, 28 Jul 2005 12:57:03 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCCO-0003Ro-Ie for simple@ietf.org; Thu, 28 Jul 2005 13:29:39 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2005 09:56:53 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j6SGurJL005791; Thu, 28 Jul 2005 09:56:53 -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); Thu, 28 Jul 2005 12:56:52 -0400 Received: from cisco.com ([161.44.79.84]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 12:56:52 -0400 Message-ID: <42E90E54.9000500@cisco.com> Date: Thu, 28 Jul 2005 12:56:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARJOU Xavier RD-MAPS-LAN Subject: Re: [Simple] Comment about draft-ietf-simple-event-list-07.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2005 16:56:52.0753 (UTC) FILETIME=[5A7DC810:01C59395] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Xavier, I differ with your interpretation of this. The RLS acts as a watcher for each element of the event list. The corresponding notifier must make any privacy filtering decisions based on the identity the RLS presents when subscribing. One would hope that the RLS will, if it can, use the identity of the subscriber to the RLS, or some identity that is uniquely associated to that of that subscriber. But the details of that are implementation issues. If an RLS supports many subscribers but can only assert a single identity then information it gets may be distribted to many. When presentities set up their authorization rules they should be circumspect in what they disclose to an RLS. This is no different than a person being careful not to tell secrets to someone known to gossip. Paul MARJOU Xavier RD-MAPS-LAN wrote: > Hi, > > In "Section 6 Example", the Presence document of some presentities is > sent directly by the RLS in F3. This must not possible because Privacy > Filtering is not executed at the RLS, but at the Presence Server of each > presentity. Thus immediate answer from RLS breaks "privacy filtering" of > those presentities. > > I think this suggested by the sentence "RLS is also an authority for > presence information for the users in the vancouver.example.com > domain.", but I think it is worth underlying this "privacy filtering" > aspect. > > Xavier > > _______________________________________________ > 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 28 17:10:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyFdr-0004p6-E0; Thu, 28 Jul 2005 17:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyFdn-0004iH-3q for simple@megatron.ietf.org; Thu, 28 Jul 2005 17:10:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29178 for ; Thu, 28 Jul 2005 17:10:04 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyG9I-0001zP-3Z for simple@ietf.org; Thu, 28 Jul 2005 17:42:42 -0400 Received: from [192.168.1.103] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j6SL8Pgk031250 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 28 Jul 2005 16:08:26 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] New version of MSRP and MSRP relay Date: Thu, 28 Jul 2005 16:08:19 -0500 To: Nancy Greene (QC/EMC) X-Mailer: Apple Mail (2.733) Received-SPF: pass (nostrum.com: 67.164.135.116 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Rohan Mahy , 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Jul 25, 2005, at 3:35 PM, Nancy Greene (QC/EMC) wrote: > Hi, here are some comments on MSRP-11: > > - The section listing differences from previous versions has been > removed. Are all differences from -10 editorial? > > No, but the non-editorial changes we published on this list a while back. The changes section was removed at chair direction--I assume to get ready for submission to IESG. > Editorial comments: > - 2nd last paragraph in section 7.1: The following text is now > covered in paragraphs 3&4 in section 7.1, so the following should > be deleted: > > " Finally, requests which have no body MUST NOT contain a Content- > Type > header or any other MIME specific header. Requests without bodies > MUST contain a end-line after the final header." > > - section 7.3.2, 5th paragraph - change "when and endpoint" to > "when an endpoint" Thanks--will fix. > Nancy > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > Sent: Monday, July 18, 2005 3:44 PM > To: simple@ietf.org > Cc: Cullen Jennings; Adam Roach; Rohan Mahy > Subject: [Simple] New version of MSRP and MSRP relay > > > > Until they show up, you can find them at: > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple- > message-s > essions-11.html > > and > > http://scm.sipfoundry.org/rep/ietf-drafts/simple/draft-ietf-simple- > msrp-rela > ys-05.html > > Sorry if these URL get cut up - There are also ascii versions with > a .txt > file extension > > Cullen > > > _______________________________________________ > 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 Thu Jul 28 22:01:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyKCD-0002d2-F1; Thu, 28 Jul 2005 22:01:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsgyi-0004SK-2c for simple@megatron.ietf.org; Wed, 13 Jul 2005 09:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04630 for ; Wed, 13 Jul 2005 09:08:42 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DshR6-0007sw-5N for simple@ietf.org; Wed, 13 Jul 2005 09:38:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 13 Jul 2005 16:05:51 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CBECB8E@mail.followap.com> Thread-Topic: draft-brok-simple-regulate-publish Thread-Index: AcWHquLKnUIBx7fHTua7q6ba2nY5gQ== From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 X-Mailman-Approved-At: Thu, 28 Jul 2005 22:01:54 -0400 Cc: simple@ietf.org Subject: [Simple] draft-brok-simple-regulate-publish 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="===============0769495377==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0769495377== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C587AB.983CFB62" This is a multi-part message in MIME format. ------_=_NextPart_001_01C587AB.983CFB62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 What is the status of interest of SIMPLE in this I/D? Do you plan a revision? =20 The MIME type of an event package, usually defines the NOTIFY body, and in presence - the PUBLISH body as well. For the SUBSCRIBE body, it is usually defined to be a filtering request and is NOT having the same structure as the information above. =20 In 4.2, it seems you try to re-use the same MIME (by adding a limitation " should be ignored by the server"). This practice seems not to fit the other event packages defined, and also creates ambiguity what exactly the MIME corresponds to. Did you specify this for simplicity? =20 Cheers, --Fridy / Followap ------_=_NextPart_001_01C587AB.983CFB62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

What is the status of interest of SIMPLE in this I/D? = Do you plan a revision?

 

The MIME type of an event package, usually defines = the NOTIFY body, and in presence – the PUBLISH body as = well.

For the SUBSCRIBE body, it is usually defined to be a filtering request and is NOT having the same structure as the = information above.

 

In 4.2, it seems you try to re-use the same MIME (by = adding a limitation “<constraint> should be ignored by the = server”). This practice seems not to fit the other event packages defined, and = also creates ambiguity what exactly the MIME corresponds to. Did you specify = this for simplicity?

 

Cheers,

--Fridy / Followap

------_=_NextPart_001_01C587AB.983CFB62-- --===============0769495377== 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 --===============0769495377==-- From simple-bounces@ietf.org Thu Jul 28 22:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyKCE-0002dS-6s; Thu, 28 Jul 2005 22:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsio1-0003L9-Ow for simple@megatron.ietf.org; Wed, 13 Jul 2005 11:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16227 for ; Wed, 13 Jul 2005 11:05:47 -0400 (EDT) Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsjGQ-0004b3-CN for simple@ietf.org; Wed, 13 Jul 2005 11:35:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [SIMPLE] presence processing model I/D Date: Wed, 13 Jul 2005 18:00:09 +0300 Message-ID: <8E5AB0A04458904BB9B079055261033CBECC26@mail.followap.com> Thread-Topic: [SIMPLE] presence processing model I/D Thread-Index: AcWHutvbFk1jsxvnQ/eZzlpfPy/mtQ== From: "Fridy Sharon-Fridman" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-Mailman-Approved-At: Thu, 28 Jul 2005 22:01:54 -0400 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="===============1786616316==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1786616316== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C587BB.8FD6EF52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C587BB.8FD6EF52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 In 3.2 and example is given for "overriding" with Home and Office PC both with IM application. The example states different "service": That IM service uses a different service URI than the one at work, since the two are running on separate UA instances. =20 =20 Isn't it more appropriate, under PDM, to assume these are different devices (possibly both enlisted under the same service in the tuple element, but their "device" related information is different) rather than different services? Currently device information is limited and may be the reason for above example choosing different service, but it seems unnatural, when specifying directly that it is the same IM service, but a different device (home PC vs. Office PC). =20 --Fridy / Followap ------_=_NextPart_001_01C587BB.8FD6EF52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In 3.2 and example is given for = “overriding” with Home and Office PC both with IM = application.

The example states different = “service”:

That IM service uses a different service URI than the one = at work, since the two are running on separate UA instances.  =

 

Isn’t it more appropriate, under PDM, to assume = these are different devices (possibly both enlisted under the same service in = the tuple element, but their “device” related information is = different) rather than different services? Currently device information is limited = and may be the reason for above example choosing different service, but it seems unnatural, when specifying directly that it is the same IM service, but = a different device (home PC vs. Office PC).

 

--Fridy / Followap

------_=_NextPart_001_01C587BB.8FD6EF52-- --===============1786616316== 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 --===============1786616316==-- From simple-bounces@ietf.org Thu Jul 28 22:01:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyKCE-0002du-Vw; Thu, 28 Jul 2005 22:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWVa-00022S-9Q; Tue, 26 Jul 2005 16:58:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23597; Tue, 26 Jul 2005 16:58:36 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxX0h-0001yX-VP; Tue, 26 Jul 2005 17:30:48 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 13:58:27 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 13:58:26 -0700 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, 26 Jul 2005 13:58:19 -0700 Message-ID: Thread-Topic: [Sipping] Inter-Domain Requirements for SIP/SIMPLE Thread-Index: AcWR3zae3zPgzAmKTt6LqgsBibwVwAAH4ThQAAMj4DAAAi+nIA== From: "Orit Levin" To: "Michael Hammer \(mhammer\)" , , , , , X-OriginalArrivalTime: 26 Jul 2005 20:58:26.0615 (UTC) FILETIME=[C4AE1C70:01C59224] X-Spam-Score: 1.3 (+) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 28 Jul 2005 22:01:55 -0400 Cc: hardie@qualcomm.com, Jake Salinger , sah@428cobrajet.net, Dean Willis Subject: [Simple] RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org We (i.e. the co-authors) obviously think that the document is useful. It has served us very well as a working tool for deploying public to enterprise IM connectivity. We are still constantly referring our customers and competitors interested in this type of interconnection to it. We planned to present the draft at SIMPLE or SIPPING, but currently there are no time slots available on either. The reason for presenting the draft was to figure out the best way forward: an individual informational RFC vs. a WG BCP. In other words, we wanted to raise the exact three questions that Michael is asking below in his email. Regarding presenting the draft at the VoIP Peering BoF - the authors feel very hesitant about it. For the "profile" and the specific SIMPLE requirements talked about in this draft - there is really no need to establish a new WG. We believe that they all naturally fall under SIP and SIMPLE. It is true that Service Providers will most probably need a similar profile as a part of their connectivity but they are currently looking for a much broader scope - beyond the standard SIP/SIMPLE. I am bcc-ing SIMPLE as well, but let's keep this thread on SIPPING. Thanks, Orit. > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behalf > Of Michael Hammer (mhammer) > Sent: Tuesday, July 26, 2005 11:03 AM > To: henry@pulver.com; rjsparks@nostrum.com; hisham.khartabil@telio.no; > sipping@ietf.org; gonzalo.camarillo@ericsson.com > Cc: hardie@qualcomm.com; Jake Salinger; sah@428cobrajet.net; Dean Willis > Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE >=20 > Henry, >=20 > I too agree that there is some good information in this document. But, > my question to the group is whether that is sufficient reason for the > group to take on this *type* of work. My impression is that in the past > such work was deemed out of scope. (Implementation-oriented, "we don't > do profiles", etc.) The questions that should be addressed before this > one: >=20 > 1. Will adding this to the workload delay existing WG items further? >=20 > 2. Will adding this to the workload preclude other more core protocol > work from being added as WG items and addressed in a timely fashion? >=20 > 3. How will this group deal with other fora that are doing similar > work? >=20 > Perhaps the VoIP Peering BoF will also touch on the above. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Henry Sinnreich > > Sent: Tuesday, July 26, 2005 12:59 PM > > To: rjsparks@nostrum.com; hisham.khartabil@telio.no; > > sipping@ietf.org; gonzalo.camarillo@ericsson.com > > Cc: hardie@qualcomm.com; 'Jake Salinger'; > > sah@428cobrajet.net; 'Dean Willis' > > Subject: FW: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > > > > > > >It should definitely become a SIPPING WG item. This document > > is great. > > > > If Dean thought this request can be dismissed with a joke: We > > will be persistent. > > > > Especially in view of the VoIP Peering BOF. > > > > Thanks, Henry > > > > > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Jake Salinger > > Sent: Monday, July 25, 2005 7:30 AM > > To: sipping@ietf.org > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > > > > It should definitely become a SIPPING WG item. This document is great. > > > > > > > > > > ----- Original Message ----- > > From: > > To: "'Dean Willis'" ; > > Cc: > > Sent: Monday, July 25, 2005 4:18 PM > > Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > > > > > > > >Could we just poll the mailing list instead? > > > > > > > > http://www.ietf.org/internet-drafts/draft-levin-simple-interdo > > main-reqs-02.t > > > xt > > > > > > What are the opinions on this list? Should it become a > > SIPPING WG item? > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Sunday, July 24, 2005 6:50 PM > > > To: henry@pulver.com > > > Cc: sipping@ietf.org > > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > > > > > > > > > On Jul 23, 2005, at 9:53 AM, Henry Sinnreich wrote: > > > > > > > The I-D Inter-Domain Requirements for SIP/SIMPLE > > > > > > http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain- > > > > reqs-02.t > > > > xt > > > > > > > > is not only a very good document but is also very timely > > for other > > > > inter-domain communications, such as between all the > > emerging VoIP > > > > islands (the islands are a regrettable fact at present). > > > > > > > > I suggest therefore having a 5 minute hum so as to make > > it a SIPPING > > > > WG item. > > > > > > > > > Henry, I'm pretty sure that if we ask the working group to > > hum for 5 > > > minutes that the resulting anoxia would preclude further > > useful work > > > for the remainder of the meeting. > > > > > > Could we just poll the mailing list instead? > > > > > > -- > > > Dean > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use > > > sip-implementors@cs.columbia.edu for questions on current sip Use > > > sip@ietf.org for new developments of core SIP > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > > > > > > > > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sip@ietf.org for new developments of core SIP > > >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Jul 28 22:01:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyKCF-0002eN-Q1; Thu, 28 Jul 2005 22:01:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxWcO-0002y1-ND; Tue, 26 Jul 2005 17:05:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24003; Tue, 26 Jul 2005 17:05:38 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxX7W-00029y-Cg; Tue, 26 Jul 2005 17:37:50 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 14:05:30 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 14:05:29 -0700 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, 26 Jul 2005 14:05:25 -0700 Message-ID: Thread-Topic: [Sipping] Inter-Domain Requirements for SIP/SIMPLE Thread-Index: AcWR3zae3zPgzAmKTt6LqgsBibwVwAAH4ThQAAMj4DAABopl8A== From: "Orit Levin" To: X-OriginalArrivalTime: 26 Jul 2005 21:05:29.0979 (UTC) FILETIME=[C10654B0:01C59225] X-Spam-Score: 1.3 (+) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 28 Jul 2005 22:01:55 -0400 Cc: Subject: [Simple] RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org We (i.e. the co-authors) obviously think that the document is useful. It has served us very well as a working tool for deploying public to enterprise IM connectivity. We are still constantly referring our customers and competitors interested in this type of interconnection to it. We planned to present the draft at SIMPLE or SIPPING, but currently there are no time slots available on either. The reason for presenting the draft was to figure out the best way forward: an individual informational RFC vs. a WG BCP. In other words, we wanted to raise the exact three questions that Michael is asking below in his email. Regarding presenting the draft at the VoIP Peering BoF - the authors feel very hesitant about it. For the "profile" and the specific SIMPLE requirements talked about in this draft - there is really no need to establish a new WG. We believe that they all naturally fall under SIP and SIMPLE. It is true that Service Providers will most probably need a similar profile as a part of their connectivity but they are currently looking for a much broader scope - beyond the standard SIP/SIMPLE. I am bcc-ing SIMPLE as well, but let's keep this thread on SIPPING. Thanks, Orit. > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of Michael Hammer=20 > (mhammer) > Sent: Tuesday, July 26, 2005 11:03 AM > To: henry@pulver.com; rjsparks@nostrum.com;=20 > hisham.khartabil@telio.no; sipping@ietf.org;=20 > gonzalo.camarillo@ericsson.com > Cc: hardie@qualcomm.com; Jake Salinger; sah@428cobrajet.net;=20 > Dean Willis > Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE >=20 > Henry, >=20 > I too agree that there is some good information in this=20 > document. But, my question to the group is whether that is=20 > sufficient reason for the group to take on this *type* of=20 > work. My impression is that in the past such work was deemed=20 > out of scope. (Implementation-oriented, "we don't do=20 > profiles", etc.) The questions that should be addressed before this > one: >=20 > 1. Will adding this to the workload delay existing WG items further? >=20 > 2. Will adding this to the workload preclude other more core=20 > protocol work from being added as WG items and addressed in a=20 > timely fashion? >=20 > 3. How will this group deal with other fora that are doing=20 > similar work? >=20 > Perhaps the VoIP Peering BoF will also touch on the above. >=20 > Mike >=20 >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Henry Sinnreich > > Sent: Tuesday, July 26, 2005 12:59 PM > > To: rjsparks@nostrum.com; hisham.khartabil@telio.no;=20 > sipping@ietf.org;=20 > > gonzalo.camarillo@ericsson.com > > Cc: hardie@qualcomm.com; 'Jake Salinger';=20 > sah@428cobrajet.net; 'Dean=20 > > Willis' > > Subject: FW: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > >=20 > >=20 > > >It should definitely become a SIPPING WG item. This document > > is great.=20 > >=20 > > If Dean thought this request can be dismissed with a joke:=20 > We will be=20 > > persistent. > >=20 > > Especially in view of the VoIP Peering BOF. > >=20 > > Thanks, Henry > > =20 > >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Jake Salinger > > Sent: Monday, July 25, 2005 7:30 AM > > To: sipping@ietf.org > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > >=20 > > It should definitely become a SIPPING WG item. This=20 > document is great. > >=20 > >=20 > >=20 > >=20 > > ----- Original Message ----- > > From: > > To: "'Dean Willis'" ; > > Cc: > > Sent: Monday, July 25, 2005 4:18 PM > > Subject: RE: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > >=20 > >=20 > > > >Could we just poll the mailing list instead? > > > > > > > > http://www.ietf.org/internet-drafts/draft-levin-simple-interdo > > main-reqs-02.t > > > xt > > > > > > What are the opinions on this list? Should it become a > > SIPPING WG item? > > > > > > Thanks, Henry > > > > > > -----Original Message----- > > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > > Sent: Sunday, July 24, 2005 6:50 PM > > > To: henry@pulver.com > > > Cc: sipping@ietf.org > > > Subject: Re: [Sipping] Inter-Domain Requirements for SIP/SIMPLE > > > > > > > > > On Jul 23, 2005, at 9:53 AM, Henry Sinnreich wrote: > > > > > > > The I-D Inter-Domain Requirements for SIP/SIMPLE > > > >=20 > > http://www.ietf.org/internet-drafts/draft-levin-simple-interdomain- > > > > reqs-02.t > > > > xt > > > > > > > > is not only a very good document but is also very timely > > for other > > > > inter-domain communications, such as between all the > > emerging VoIP > > > > islands (the islands are a regrettable fact at present). > > > > > > > > I suggest therefore having a 5 minute hum so as to make > > it a SIPPING > > > > WG item. > > > > > > > > > Henry, I'm pretty sure that if we ask the working group to > > hum for 5 > > > minutes that the resulting anoxia would preclude further > > useful work > > > for the remainder of the meeting. > > > > > > Could we just poll the mailing list instead? > > > > > > -- > > > Dean > > > > > > > > > _______________________________________________ > > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > > > > > > > > > > > > > > > _______________________________________________ > > > Sipping mailing list =20 > https://www1.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP Use=20 > > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > > sip@ietf.org for new developments of core SIP > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP Use=20 > > sip-implementors@cs.columbia.edu for questions on current sip Use=20 > > sip@ietf.org for new developments of core SIP > >=20 >=20 > _______________________________________________ > Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP=20 > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sip@ietf.org for new developments of core SIP >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 29 09:59:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyVO9-0001MC-Fx; Fri, 29 Jul 2005 09:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyVO5-0001Ld-QR; Fri, 29 Jul 2005 09:58:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09934; Fri, 29 Jul 2005 09:58:55 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyVtk-0002D1-T2; Fri, 29 Jul 2005 10:31:42 -0400 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j6TDwY1l000305 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 29 Jul 2005 08:58:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 29 Jul 2005 08:58:36 -0500 To: Simple WG , sip-implementors@cs.columbia.edu, "sip@ietf.org WG" X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Simple] SIPIT 17 registration closes in two weeks 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org SIPIT 17 will take place Sep 12-16 in Stockholm, Sweden, hosted by Hotsip. Information about the event is available at sipit17.hotsip.com and www.sipit.net. Registration closes August 14 (two weeks). If you plan to attend but have not yet registered, please do so now. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Jul 29 10:59:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWKb-0002FG-Sm; Fri, 29 Jul 2005 10:59:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyWKZ-0002Dp-W1 for simple@megatron.ietf.org; Fri, 29 Jul 2005 10:59:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15407 for ; Fri, 29 Jul 2005 10:59:21 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyWqF-000488-FX for simple@ietf.org; Fri, 29 Jul 2005 11:32:08 -0400 Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j6TExHqZ005210 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 29 Jul 2005 09:59:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <182508497a2e51623f19eafaaf19564a@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Date: Fri, 29 Jul 2005 09:59:19 -0500 To: Simple WG X-Mailer: Apple Mail (2.622) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE WG Agenda with draft links / pdf reading list 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org All - This is a little late (apologies), but hopefully still useful. PDFs (1 and 2 up, letter and A4) of the drafts referenced here are available at : http://www.estacado.net/ietf/simple63/ Agenda: 10 mins - Chairs Update Status and roadmap Please be familiar with http://www.ietf.org/internet-drafts/draft-mahy-simple-xcap-alternative -01.txt http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-04.txt 15 mins - A Data Model for Presence http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data- model-03.txt Jonathan Rosenberg 15 mins - A Processing Model for Presence http://www.ietf.org/internet-drafts/draft-rosenberg-simple-presence- processing-model-00.txt Jonathan Rosenberg 15 mins - Presence Authorization Rules http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-rules -03.txt Jonathan Rosenberg 15 mins - An XML Document Format for Indicating Changes in XCAP Resources http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-diff-01.txt Jonathan Rosenberg 15 mins - XCAP Patch Operations http://www.ietf.org/internet-drafts/draft-urpalainen-simple-xcap-patch- ops-00.txt Aki Niemi 10 mins - PIDF Extension for Partial Presence http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf- format-04.txt Aki Niemi 5 mins - SIP extension for Partial Notification of Presence Information http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify -05.txt Aki Niemi 5 mins - Publication of Partial Presence Information http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-publish -03.txt Aki Niemi 15 mins - Composing Presence Information http://www.ietf.org/internet-drafts/draft-schulzrinne-simple- composition-00.txt Henning Schulzrinne 15 mins - Instant Message Delivery and Read Reports http://www.ietf.org/internet-drafts/draft-khartabil-simple-im-report -00.txt Hisham Khartabil 15 mins - IMDN for Common Presence and Instant Messaging (CPIM) Messages http://www.ietf.org/internet-drafts/draft-burger-simple-imdn-01.txt Eric Burger Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 30 10:19:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DysBs-000445-BA; Sat, 30 Jul 2005 10:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DysBp-00042c-3m for simple@megatron.ietf.org; Sat, 30 Jul 2005 10:19:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12383 for ; Sat, 30 Jul 2005 10:19:47 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyshi-0004ay-4N for simple@ietf.org; Sat, 30 Jul 2005 10:52:46 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Jul 2005 07:19:42 -0700 X-IronPort-AV: i="3.95,154,1120460400"; d="scan'208"; a="201667584:sNHT25702412" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j6UEJV6v008263 for ; Sat, 30 Jul 2005 07:19:36 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 30 Jul 2005 07:24:10 -0700 From: "Cullen Jennings" To: "Simple WG" Date: Sat, 30 Jul 2005 10:19:37 -0400 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWU/a7e5UD2UP7xTFKRnR+QohOrKw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 30 Jul 2005 14:24:10.0367 (UTC) FILETIME=[5A1C20F0:01C59512] X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Simple] niemi-simple-chat 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Just and idle thought that I suspect has been discussed in the past... If the CPIM To header was used to carry the names (or nicknames) of all the desired recipients of the message, could we avoid adding a new method? Not sure this is a good idea but what I am trying to achieve is to allow baseline MSRP clients that don't understand the extensions in the "chat specification" to be able to participate in a chat session where it just looks like a robot. Clients that did understand chat would be able to do the additional functionality of targeting messages at just a subset of the users. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Jul 30 10:37:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DysSs-000838-Vh; Sat, 30 Jul 2005 10:37:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DysSr-000833-JN for simple@megatron.ietf.org; Sat, 30 Jul 2005 10:37:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13661 for ; Sat, 30 Jul 2005 10:37:23 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dysyj-0005EL-Eg for simple@ietf.org; Sat, 30 Jul 2005 11:10:22 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6UEXW4q004271; Sat, 30 Jul 2005 17:33:33 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 30 Jul 2005 17:37:07 +0300 Received: from [172.21.34.136] ([172.21.34.136]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 30 Jul 2005 17:37:07 +0300 Message-ID: <42EB9092.8000307@nokia.com> Date: Sat, 30 Jul 2005 17:37:06 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Cullen Jennings Subject: Re: [Simple] niemi-simple-chat References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2005 14:37:07.0234 (UTC) FILETIME=[2928A020:01C59514] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Cullen, Thanks for the comments. ext Cullen Jennings wrote: > Just and idle thought that I suspect has been discussed in the past... > > If the CPIM To header was used to carry the names (or nicknames) of all the > desired recipients of the message, could we avoid adding a new method? Not > sure this is a good idea but what I am trying to achieve is to allow > baseline MSRP clients that don't understand the extensions in the "chat > specification" to be able to participate in a chat session where it just > looks like a robot. Clients that did understand chat would be able to do the > additional functionality of targeting messages at just a subset of the > users. The previous version actually talked about this; all messages sent from the MSRP switch/mixer were SENDs. That way non-chat-aware clients could render them in the normal manner. However, I think there is a privacy aspect to this. Replying to a note that was originally only supposed to be seen by a subset would be bad, so I think there would have to be some way to avoid that. The new method solves this, as those clients that don't support the method would reject the messages. Another option could be a CPIM Require token for this, althogh I suspect it isn't widely supported. That's why a new method might stand a better chance of avoiding the information leakage. Then there are many other, non-protocol means to solve the privacy issue, like prepending some [private] token to CPIM Subject, etc. So I'm open to any solution here that works, really. Cheers, Aki > > Cullen > > > _______________________________________________ > 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 Sun Jul 31 06:31:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzB68-0003bB-4p; Sun, 31 Jul 2005 06:31:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzB66-0003aa-5D for simple@megatron.ietf.org; Sun, 31 Jul 2005 06:31:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15655 for ; Sun, 31 Jul 2005 06:31:07 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBc8-0004oA-Oo for simple@ietf.org; Sun, 31 Jul 2005 07:04:18 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 31 Jul 2005 03:31:01 -0700 X-IronPort-AV: i="3.95,155,1120460400"; d="scan'208"; a="201732934:sNHT27976812" Received: from sea-alpha-e2k3.sea-alpha.cisco.com (sea-alpha-e2k3.cisco.com [10.93.132.88]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j6VAUxul022480; Sun, 31 Jul 2005 03:30:59 -0700 (PDT) Received: from FluffyNotebootk ([171.68.225.134]) by sea-alpha-e2k3.sea-alpha.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 03:35:35 -0700 From: "Cullen Jennings" To: "'Aki Niemi'" Subject: RE: [Simple] niemi-simple-chat Date: Sun, 31 Jul 2005 12:30:47 +0200 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWVFEwv9rb7VGzAS5mNQM7usvYhNwAXxcIw In-Reply-To: <42EB9092.8000307@nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 31 Jul 2005 10:35:35.0976 (UTC) FILETIME=[961BE280:01C595BB] X-Spam-Score: 1.1 (+) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'Simple 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Ok, as dean says, there are many ways to skin a cat. I guese an approach that mangled the URI would be my least favorite way to skin this one. > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Saturday, July 30, 2005 4:37 PM > To: ext Cullen Jennings > Cc: Simple WG > Subject: Re: [Simple] niemi-simple-chat > > Hi Cullen, > > Thanks for the comments. > > ext Cullen Jennings wrote: > > Just and idle thought that I suspect has been discussed in > the past... > > > > If the CPIM To header was used to carry the names (or > nicknames) of all the > > desired recipients of the message, could we avoid adding a > new method? Not > > sure this is a good idea but what I am trying to achieve is to allow > > baseline MSRP clients that don't understand the extensions > in the "chat > > specification" to be able to participate in a chat session > where it just > > looks like a robot. Clients that did understand chat would > be able to do the > > additional functionality of targeting messages at just a > subset of the > > users. > > The previous version actually talked about this; all messages > sent from > the MSRP switch/mixer were SENDs. That way non-chat-aware > clients could > render them in the normal manner. > > However, I think there is a privacy aspect to this. Replying > to a note > that was originally only supposed to be seen by a subset > would be bad, > so I think there would have to be some way to avoid that. The > new method > solves this, as those clients that don't support the method > would reject > the messages. > > Another option could be a CPIM Require token for this, > althogh I suspect > it isn't widely supported. That's why a new method might > stand a better > chance of avoiding the information leakage. > > Then there are many other, non-protocol means to solve the privacy > issue, like prepending some [private] token to CPIM Subject, > etc. So I'm > open to any solution here that works, really. > > Cheers, > Aki > > > > Cullen > > > > > > _______________________________________________ > > 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 Sun Jul 31 08:53:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzDKI-0003b9-HG; Sun, 31 Jul 2005 08:53:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzDKF-0003ad-6C; Sun, 31 Jul 2005 08:53:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22466; Sun, 31 Jul 2005 08:53:52 -0400 (EDT) Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzDqF-0001gz-9n; Sun, 31 Jul 2005 09:27:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6VCrG8A016035; Sun, 31 Jul 2005 15:53:41 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Jul 2005 15:53:01 +0300 Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 31 Jul 2005 15:45:34 +0300 Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id 8718293B6A; Sun, 31 Jul 2005 15:45:34 +0300 (EEST) Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id 726B134E; Sun, 31 Jul 2005 15:45:34 +0300 (EEST) From: Jari Urpalainen To: Simple WG Content-Type: text/plain Date: Sun, 31 Jul 2005 15:45:34 +0300 Message-Id: <1122813934.31132.7.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 31 Jul 2005 12:45:34.0349 (UTC) FILETIME=[BE4D2BD0:01C595CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: xml-dir@ietf.org Subject: [Simple] Presence Relax NG schemas 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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi all! I have submitted a draft (targeted as informational). This memo describes PIDF + extensio= n schemas written with the Relax NG schema language. These were produced be= cause with the W3C schemas it is not possible to write reasonable combinati= on presence schemas doing on-the-fly validation (because of the paranoid UP= A constraint specified in the appendix H of W3C structures spec). So these = are meant for publishers of presence information and the rules given in the= se schemas are thus stricter than the W3C schemas. Therefore, instance docu= ments that validate with these shall also validate with the W3C schemas. Th= e set incluces schemas for PIDF, datamodel, RPID, CIPID and CAPS. There are= still some minor differencies between these and PIDF extension schemas (so= me "last minute" changes in I-D's). So these are not meant to replace W3C s= chemas, they are just produced to decrease interoperability problems with "= real" implementations. W3C Schema 1.1 spec may eventually have a proper wil= dcard definition etc., but before it happens these schemas can be utilized. Any comments ?=20 Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Jul 31 10:23:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzEih-0005gX-IH; Sun, 31 Jul 2005 10:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzEif-0005gL-Os; Sun, 31 Jul 2005 10:23:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27151; Sun, 31 Jul 2005 10:23:11 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzFEh-0004og-8q; Sun, 31 Jul 2005 10:56:23 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2005 16:23:00 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6VEMuDg028357; Sun, 31 Jul 2005 16:22:57 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 31 Jul 2005 16:22:56 +0200 Received: from [86.255.25.104] ([10.58.48.33]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 16:22:55 +0200 Message-ID: <42ECDEBF.9080502@cisco.com> Date: Sun, 31 Jul 2005 10:22:55 -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: Jari Urpalainen Subject: Re: [Simple] Presence Relax NG schemas References: <1122813934.31132.7.camel@hed034-145.research.nokia.com> In-Reply-To: <1122813934.31132.7.camel@hed034-145.research.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2005 14:22:55.0652 (UTC) FILETIME=[57FD4640:01C595DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Simple WG , xml-dir@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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I don't have any particular views on the pros/cons of XML schema vs. relax NG. However, my concern about this is whether there is value in having TWO definitions of the grammar for these documents. It seems that this is a recipe for interoperability problems. An XML-schema-using implementation might define a document that is valid according to the schema, but invalid according to the RELAX-NG definition. That would be a problem. If that never happens, and neither can the converse (a RELAX-NG compliant document that is not schema compliant), then the RELAX-NG description is isomorphic to the XML schema, and so what is the value exactly? -Jonathan R. Jari Urpalainen wrote: > Hi all! > > I have submitted a draft > > (targeted as informational). This memo describes PIDF + extension > schemas written with the Relax NG schema language. These were > produced because with the W3C schemas it is not possible to write > reasonable combination presence schemas doing on-the-fly validation > (because of the paranoid UPA constraint specified in the appendix H > of W3C structures spec). So these are meant for publishers of > presence information and the rules given in these schemas are thus > stricter than the W3C schemas. Therefore, instance documents that > validate with these shall also validate with the W3C schemas. The set > incluces schemas for PIDF, datamodel, RPID, CIPID and CAPS. There are > still some minor differencies between these and PIDF extension > schemas (some "last minute" changes in I-D's). So these are not meant > to replace W3C schemas, they are just produced to decrease > interoperability problems with "real" implementations. W3C Schema 1.1 > spec may eventually have a proper wildcard definition etc., but > before it happens these schemas can be utilized. > > Any comments ? Jari > > > > > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture 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 Sun Jul 31 11:38:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzFtS-0003mF-47; Sun, 31 Jul 2005 11:38:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzFtQ-0003m4-1B; Sun, 31 Jul 2005 11:38:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02802; Sun, 31 Jul 2005 11:38:21 -0400 (EDT) Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzGPS-0000Mf-Vf; Sun, 31 Jul 2005 12:11:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6VFWRvP006980; Sun, 31 Jul 2005 18:32:28 +0300 Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 31 Jul 2005 18:36:16 +0300 Received: from [86.255.21.129] ([10.162.252.217]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 31 Jul 2005 18:36:16 +0300 Message-ID: <42ECEFEF.3050001@nokia.com> Date: Sun, 31 Jul 2005 18:36:15 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Simple] Presence Relax NG schemas References: <1122813934.31132.7.camel@hed034-145.research.nokia.com> <42ECDEBF.9080502@cisco.com> In-Reply-To: <42ECDEBF.9080502@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 31 Jul 2005 15:36:16.0390 (UTC) FILETIME=[97089A60:01C595E5] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext03.nokia.com id j6VFWRvP006980 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: Jari Urpalainen , Simple WG , xml-dir@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: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Perhaps this is exactly the type of activity that should take place in=20 the future SIMPLEt events. As I understand the issue, creating an =FCber=20 schema from the various PIDF + extension schemas isn't exactly straight=20 forward (because of the UPA issue). So I would consider this as a helper=20 in doing document validation for implementors. As an aside, I use the xml2rfc tool as probably most of you do, and I=20 use Relax NG schema (that I converted from Marshall's DTD) to validate=20 my drafts. And it seems to work fine. I think the Relax NG schema should simply be something that implementors=20 can take, validate their presence documents and (after the dust settles)=20 see what happened vs. the XML schema validation. If there are=20 differencies, then that info is probably very valuable. There is a bigger issue here: do we mandate that the presence documents=20 are always validated using XML schema only, or is e.g. Relax NG also=20 allowed? Cheers, Aki ext Jonathan Rosenberg wrote: > I don't have any particular views on the pros/cons of XML schema vs.=20 > relax NG. However, my concern about this is whether there is value in=20 > having TWO definitions of the grammar for these documents. It seems tha= t=20 > this is a recipe for interoperability problems. An XML-schema-using=20 > implementation might define a document that is valid according to the=20 > schema, but invalid according to the RELAX-NG definition. That would be= =20 > a problem. If that never happens, and neither can the converse (a=20 > RELAX-NG compliant document that is not schema compliant), then the=20 > RELAX-NG description is isomorphic to the XML schema, and so what is th= e=20 > value exactly? >=20 > -Jonathan R. >=20 > Jari Urpalainen wrote: >=20 >> Hi all! >> >> I have submitted a draft=20 >> =20 >> >> (targeted as informational). This memo describes PIDF + extension >> schemas written with the Relax NG schema language. These were >> produced because with the W3C schemas it is not possible to write >> reasonable combination presence schemas doing on-the-fly validation >> (because of the paranoid UPA constraint specified in the appendix H >> of W3C structures spec). So these are meant for publishers of >> presence information and the rules given in these schemas are thus >> stricter than the W3C schemas. Therefore, instance documents that >> validate with these shall also validate with the W3C schemas. The set >> incluces schemas for PIDF, datamodel, RPID, CIPID and CAPS. There are >> still some minor differencies between these and PIDF extension >> schemas (some "last minute" changes in I-D's). So these are not meant >> to replace W3C schemas, they are just produced to decrease >> interoperability problems with "real" implementations. W3C Schema 1.1 >> spec may eventually have a proper wildcard definition etc., but >> before it happens these schemas can be utilized. >> >> Any comments ? Jari >> >> >> >> >> >> _______________________________________________ Simple mailing list=20 >> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple