From simple-admin@ietf.org Sat Nov 1 01:18:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04418; Sat, 1 Nov 2003 01:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFp5R-00059h-00; Sat, 01 Nov 2003 01:18:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFp5Q-00059e-00; Sat, 01 Nov 2003 01:18:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFp5E-0007W8-Js; Sat, 01 Nov 2003 01:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFp4J-0007Nx-KX for simple@optimus.ietf.org; Sat, 01 Nov 2003 01:17:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04391; Sat, 1 Nov 2003 01:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFp4F-000593-00; Sat, 01 Nov 2003 01:16:59 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AFp4E-00058m-00; Sat, 01 Nov 2003 01:16:59 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA16GEYe020283; Sat, 1 Nov 2003 01:16:14 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA16GAv02338; Sat, 1 Nov 2003 01:16:11 -0500 Message-ID: <3FA34FAD.2020500@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: "'Jonathan Rosenberg'" , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 01 Nov 2003 01:16:13 -0500 Content-Transfer-Encoding: 7bit [Starting clean...] There are two somewhat separate issues: (1) Splitting into domain and user components, i.e., we could have permissions that apply to all users in a domain and some that apply to only specific users. That, by itself, does not break the additive model, if specific users have at least the permissions of the specific users within the domain. While I don't believe that, in practice, domain-specific permissions are all that useful for organizations of non-trivial size, the model of "everybody within domain gets baseline permissions, special people get more" seems plausible. There may be other issues with the split, along the "can this be generalized" question posed by Hannes, but other than modest additional complexity, this seems conceptually plausible. (2) I share Hannes concern about making exceptions on any field, including the user or domain match. I don't see the real-world motivation for this and it complicates the conceptual model. (In the geopriv interim we discussed at length as to why blacklists are generally a bad idea, even with authentication, unless you can guarantee that the bad guys you want to keep out can't change their verified identity to a new one.) At one point, I thought the basic design principle was that we weren't done until we couldn't *remove* any features - with policies, it's always tempting to pile on more and more "could be useful somewhere" items, so I think proponents of particular items should be held to a fairly high standard of proof as to why a particular feature is absolutely, positively necessary for a first version. In the geopriv draft, we spend some time talking about future extensions and how they are privacy-safe under certain baseline assumptions. We can't anticipate all the things that we might need and the things that turn out to be less than useful in practice, so I'd much rather start clean and small and then expand based on implementation experience. We just don't have a whole lot (if any) experience with policy languages or rule sets in the IETF. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 1 01:18:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04468 for ; Sat, 1 Nov 2003 01:18:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFp5Y-0007ZR-EM for simple-archive@odin.ietf.org; Sat, 01 Nov 2003 01:18:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA16IKAi029095 for simple-archive@odin.ietf.org; Sat, 1 Nov 2003 01:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFp5Y-0007ZC-9n for simple-web-archive@optimus.ietf.org; Sat, 01 Nov 2003 01:18:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04418; Sat, 1 Nov 2003 01:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFp5R-00059h-00; Sat, 01 Nov 2003 01:18:13 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFp5Q-00059e-00; Sat, 01 Nov 2003 01:18:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFp5E-0007W8-Js; Sat, 01 Nov 2003 01:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFp4J-0007Nx-KX for simple@optimus.ietf.org; Sat, 01 Nov 2003 01:17:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04391; Sat, 1 Nov 2003 01:16:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFp4F-000593-00; Sat, 01 Nov 2003 01:16:59 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AFp4E-00058m-00; Sat, 01 Nov 2003 01:16:59 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA16GEYe020283; Sat, 1 Nov 2003 01:16:14 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA16GAv02338; Sat, 1 Nov 2003 01:16:11 -0500 Message-ID: <3FA34FAD.2020500@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: "'Jonathan Rosenberg'" , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 01 Nov 2003 01:16:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Starting clean...] There are two somewhat separate issues: (1) Splitting into domain and user components, i.e., we could have permissions that apply to all users in a domain and some that apply to only specific users. That, by itself, does not break the additive model, if specific users have at least the permissions of the specific users within the domain. While I don't believe that, in practice, domain-specific permissions are all that useful for organizations of non-trivial size, the model of "everybody within domain gets baseline permissions, special people get more" seems plausible. There may be other issues with the split, along the "can this be generalized" question posed by Hannes, but other than modest additional complexity, this seems conceptually plausible. (2) I share Hannes concern about making exceptions on any field, including the user or domain match. I don't see the real-world motivation for this and it complicates the conceptual model. (In the geopriv interim we discussed at length as to why blacklists are generally a bad idea, even with authentication, unless you can guarantee that the bad guys you want to keep out can't change their verified identity to a new one.) At one point, I thought the basic design principle was that we weren't done until we couldn't *remove* any features - with policies, it's always tempting to pile on more and more "could be useful somewhere" items, so I think proponents of particular items should be held to a fairly high standard of proof as to why a particular feature is absolutely, positively necessary for a first version. In the geopriv draft, we spend some time talking about future extensions and how they are privacy-safe under certain baseline assumptions. We can't anticipate all the things that we might need and the things that turn out to be less than useful in practice, so I'd much rather start clean and small and then expand based on implementation experience. We just don't have a whole lot (if any) experience with policy languages or rule sets in the IETF. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 3 04:25:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24741; Mon, 3 Nov 2003 04:25:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaxT-0002VE-00; Mon, 03 Nov 2003 04:25:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGaxT-0002V8-00; Mon, 03 Nov 2003 04:25:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaxK-0000I7-Cn; Mon, 03 Nov 2003 04:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGawv-0000HP-Mu for simple@optimus.ietf.org; Mon, 03 Nov 2003 04:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24729 for ; Mon, 3 Nov 2003 04:24:26 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaws-0002Uy-00 for simple@ietf.org; Mon, 03 Nov 2003 04:24:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGaws-0002Uv-00 for simple@ietf.org; Mon, 03 Nov 2003 04:24:34 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA39OYF05798 for ; Mon, 3 Nov 2003 11:24:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 11:24:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 11:24:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Thread-Index: AcOfvObWxobrzw56SHaj27G0udXU+gCGOnmg To: , Cc: X-OriginalArrivalTime: 03 Nov 2003 09:24:32.0907 (UTC) FILETIME=[4A662DB0:01C3A1EC] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Nov 2003 11:24:32 +0200 Content-Transfer-Encoding: quoted-printable Hi, Inline > >=20 > >>I see that this revision has tried to align the format of the new=20 > >>elements with the other elements in PIDF and RPIDS. > Stylistically that > >>is good. > >> > >>But, in the process, something important has been lost. In=20 > >>draft-ietf-sip-callee-caps-01 there is the possibility of > using both > >>base-tags defined explicitly in that document, and other-tags. But=20 > >>prescaps only represents the base-tags. I think it is important to=20 > >>provide a representation for those as well. > >=20 > >=20 > > Yes, I also think that support for other-tags would be good. During=20 > > update I wasn't able to come up with any good solution so I just=20 > > dropped it. > > =20 > >=20 > >>Additionally, the xml representations of the values for > base-tags does > >>not cover the range of possibilities defined in callee-caps. > >=20 > >=20 > > Could you be bit more specific. Do you meant that for example for > > element XML schema should define the exact structure how=20 > > method names should be presented? >=20 > No. I mean your xml format doesn't cover: > - negation Correct, this seems to be missing from all string typed attributes. For boolean types value 'false' can probably be interpreted as negation.=20 There are currently two ways that String types are used: - enumerated types (like class) - lists (like methods) For enumeration types negation is easily added into XML syntax. For lists this is not that trivial. One option is to add negation as ! mark into value string like: INVITE, !MESSAGE. Other alternative would be to redesign these lists bit differently like: INVITE MESSAGE> =20 Second alternative is bit heavier one but I still think it is the better one.=20 > - number ranges Do you mean for 'priority' tag? If yes I can add it to next version. > - distinction between tokens and strings > (tokens use case-insensitive compare, > strings use case-sensitive compare) For me it is not clear what is the intended usage of comparison operations is this context. There are at least two cases: 1) XML document level comparison So, in this case two XML documents (or parts if them) are compared directly. I am not aware of any XML representation which would allow these type of operations (case insensitive/sensitive) and also I am not sure if this is relevant case for us.=20 2) Element value comparison In this case you would extract the values of the XML elements and then compare the extracted values. Here we can do: - Specify these things in the draft (no XML representation) - Add new attribute into XML structure like which = can specify if element contains case sensitive or insensitive data.=20 =20 > >>2) use the literal string representation used in contact headers > >> in draft-ietf-sip-callee-caps-01. > >> > >> pros: the mapping is straightforward; it covers all cases; > >> easy to use the same matching algorithm with both > >> presence data and registration data > >> > >> cons: it isn't very user friendly if ever presented directly > >> to a user; it isn't a very convenient representation > >> for code that doesn't need to implement the matching alg. > >=20 > >=20 > > I am not sure if this is that big problem. I would think > that if client > > does not know how what particular attribute means it probably won't > > display it to the user. At least you probably cannot expect > client to > > take any actions based on attributes which it doesn't understand. >=20 > You will note that I concluded this was the best alternative in spite=20 > of the limitations. I mentioned them in the interest of trying to do=20 > an honest evaluation of the alternatives. >=20 > > For me option 2 sounds ok. I will modify draft accordingly if nobody > > objects. >=20 > Sounds good to me, but it would be nice to get input from others. Definitely > If you look closely at the examples I provided, I sidestepped one=20 > issue: >=20 > I didn't show how to represent the distinction between strings and=20 > tokens. In callee-caps it is done as "token" vs " string>". My > xml skills aren't very good, and so I don't have a clear idea what=20 > would be the best way to render this difference in xml. But I do know=20 > that > rendering: >=20 > description=3D"" > as: > >=20 > is *not* the answer! So I need a suggestion from somebody on how best=20 > to do this. How about: Well, now that I spend some time looking your proposal there seems to be few things which needs to be fixed. I think it is not possible to define something like: !en This can be fixed at least in two ways: 1) !en 2) language !en I would think second one is better as all the required data can be retrieved from XML document directly. And if we add all the other things we end up with: language en - Mikko >=20 > > There are also some other open issues with existing draft > and I will try > > to compose a separate mail about those before the next meeting. > >=20 > > - Mikko > >=20 > >=20 > >>The following is the example from prescaps, extended in this way: > >> > >> > >> >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > >> xsi:schemaLocation=3D"urn:ietf:params:xml:ns:pidf" > >> xmlns:ext=3D"urn:ietf:params:xml:ns:simple-prescaps-ext" > >> entity=3D"pres:someone@example.com"> > >> > >> > >> > >> open > >> > >> true > >> true > >> true > >> INVITE,MESSAGE, > >> ACK,BYE,CANCEL > >> > >> #=3D5,!#<=3D10 > >> > >> !en > >> > >> !red,blue > >> > >> TRUE > >> > >> > >> sip:someone@examaple.com > >> > >> > >> > >>This is equivalent to the following contact: > >> > >> Contact: sip:someone@examaple.com; > >> video;audio;mobile; > >> methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > >> +sip.priority=3D"#=3D5,!#<=3D10" > >> +language=3D"!en"; > >> +g.sip!foo@tags.example.com=3D"!red,blue"; > >> +g.sip!bar@tags.example.com; > >> > >>or equivalently: > >> > >> Contact: sip:someone@examaple.com; > >> video;audio;mobile; > >> methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > >> priority=3D"#=3D5,!#<=3D10"; > >> language=3D"!en" > >> +g.sip!foo@tags.example.com=3D"!red,blue"; > >> +g.sip!bar@tags.example.com > >> > >>Note that not only does this address other tags, it also addresses=20 > >>values for base-tags that are more complex than the simple=20 > >>representation can handle. > >> > >> Paul > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 3 04:25:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24757 for ; Mon, 3 Nov 2003 04:25:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaxX-0000J7-MO for simple-archive@odin.ietf.org; Mon, 03 Nov 2003 04:25:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA39PF58001180 for simple-archive@odin.ietf.org; Mon, 3 Nov 2003 04:25:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaxW-0000It-Vi for simple-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 04:25:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24741; Mon, 3 Nov 2003 04:25:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaxT-0002VE-00; Mon, 03 Nov 2003 04:25:11 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGaxT-0002V8-00; Mon, 03 Nov 2003 04:25:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGaxK-0000I7-Cn; Mon, 03 Nov 2003 04:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGawv-0000HP-Mu for simple@optimus.ietf.org; Mon, 03 Nov 2003 04:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24729 for ; Mon, 3 Nov 2003 04:24:26 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaws-0002Uy-00 for simple@ietf.org; Mon, 03 Nov 2003 04:24:34 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AGaws-0002Uv-00 for simple@ietf.org; Mon, 03 Nov 2003 04:24:34 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA39OYF05798 for ; Mon, 3 Nov 2003 11:24:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 11:24:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 3 Nov 2003 11:24:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Thread-Index: AcOfvObWxobrzw56SHaj27G0udXU+gCGOnmg To: , Cc: X-OriginalArrivalTime: 03 Nov 2003 09:24:32.0907 (UTC) FILETIME=[4A662DB0:01C3A1EC] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 3 Nov 2003 11:24:32 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Inline > >=20 > >>I see that this revision has tried to align the format of the new=20 > >>elements with the other elements in PIDF and RPIDS. > Stylistically that > >>is good. > >> > >>But, in the process, something important has been lost. In=20 > >>draft-ietf-sip-callee-caps-01 there is the possibility of > using both > >>base-tags defined explicitly in that document, and other-tags. But=20 > >>prescaps only represents the base-tags. I think it is important to=20 > >>provide a representation for those as well. > >=20 > >=20 > > Yes, I also think that support for other-tags would be good. During=20 > > update I wasn't able to come up with any good solution so I just=20 > > dropped it. > > =20 > >=20 > >>Additionally, the xml representations of the values for > base-tags does > >>not cover the range of possibilities defined in callee-caps. > >=20 > >=20 > > Could you be bit more specific. Do you meant that for example for > > element XML schema should define the exact structure how=20 > > method names should be presented? >=20 > No. I mean your xml format doesn't cover: > - negation Correct, this seems to be missing from all string typed attributes. For boolean types value 'false' can probably be interpreted as negation.=20 There are currently two ways that String types are used: - enumerated types (like class) - lists (like methods) For enumeration types negation is easily added into XML syntax. For lists this is not that trivial. One option is to add negation as ! mark into value string like: INVITE, !MESSAGE. Other alternative would be to redesign these lists bit differently like: INVITE MESSAGE> =20 Second alternative is bit heavier one but I still think it is the better one.=20 > - number ranges Do you mean for 'priority' tag? If yes I can add it to next version. > - distinction between tokens and strings > (tokens use case-insensitive compare, > strings use case-sensitive compare) For me it is not clear what is the intended usage of comparison operations is this context. There are at least two cases: 1) XML document level comparison So, in this case two XML documents (or parts if them) are compared directly. I am not aware of any XML representation which would allow these type of operations (case insensitive/sensitive) and also I am not sure if this is relevant case for us.=20 2) Element value comparison In this case you would extract the values of the XML elements and then compare the extracted values. Here we can do: - Specify these things in the draft (no XML representation) - Add new attribute into XML structure like which = can specify if element contains case sensitive or insensitive data.=20 =20 > >>2) use the literal string representation used in contact headers > >> in draft-ietf-sip-callee-caps-01. > >> > >> pros: the mapping is straightforward; it covers all cases; > >> easy to use the same matching algorithm with both > >> presence data and registration data > >> > >> cons: it isn't very user friendly if ever presented directly > >> to a user; it isn't a very convenient representation > >> for code that doesn't need to implement the matching alg. > >=20 > >=20 > > I am not sure if this is that big problem. I would think > that if client > > does not know how what particular attribute means it probably won't > > display it to the user. At least you probably cannot expect > client to > > take any actions based on attributes which it doesn't understand. >=20 > You will note that I concluded this was the best alternative in spite=20 > of the limitations. I mentioned them in the interest of trying to do=20 > an honest evaluation of the alternatives. >=20 > > For me option 2 sounds ok. I will modify draft accordingly if nobody > > objects. >=20 > Sounds good to me, but it would be nice to get input from others. Definitely > If you look closely at the examples I provided, I sidestepped one=20 > issue: >=20 > I didn't show how to represent the distinction between strings and=20 > tokens. In callee-caps it is done as "token" vs " string>". My > xml skills aren't very good, and so I don't have a clear idea what=20 > would be the best way to render this difference in xml. But I do know=20 > that > rendering: >=20 > description=3D"" > as: > >=20 > is *not* the answer! So I need a suggestion from somebody on how best=20 > to do this. How about: Well, now that I spend some time looking your proposal there seems to be few things which needs to be fixed. I think it is not possible to define something like: !en This can be fixed at least in two ways: 1) !en 2) language !en I would think second one is better as all the required data can be retrieved from XML document directly. And if we add all the other things we end up with: language en - Mikko >=20 > > There are also some other open issues with existing draft > and I will try > > to compose a separate mail about those before the next meeting. > >=20 > > - Mikko > >=20 > >=20 > >>The following is the example from prescaps, extended in this way: > >> > >> > >> >> xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" > >> xsi:schemaLocation=3D"urn:ietf:params:xml:ns:pidf" > >> xmlns:ext=3D"urn:ietf:params:xml:ns:simple-prescaps-ext" > >> entity=3D"pres:someone@example.com"> > >> > >> > >> > >> open > >> > >> true > >> true > >> true > >> INVITE,MESSAGE, > >> ACK,BYE,CANCEL > >> > >> #=3D5,!#<=3D10 > >> > >> !en > >> > >> !red,blue > >> > >> TRUE > >> > >> > >> sip:someone@examaple.com > >> > >> > >> > >>This is equivalent to the following contact: > >> > >> Contact: sip:someone@examaple.com; > >> video;audio;mobile; > >> methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > >> +sip.priority=3D"#=3D5,!#<=3D10" > >> +language=3D"!en"; > >> +g.sip!foo@tags.example.com=3D"!red,blue"; > >> +g.sip!bar@tags.example.com; > >> > >>or equivalently: > >> > >> Contact: sip:someone@examaple.com; > >> video;audio;mobile; > >> methods=3D"INVITE,MESSAGE,ACK,BYE,CANCEL"; > >> priority=3D"#=3D5,!#<=3D10"; > >> language=3D"!en" > >> +g.sip!foo@tags.example.com=3D"!red,blue"; > >> +g.sip!bar@tags.example.com > >> > >>Note that not only does this address other tags, it also addresses=20 > >>values for base-tags that are more complex than the simple=20 > >>representation can handle. > >> > >> Paul > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 3 10:14:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05917; Mon, 3 Nov 2003 10:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgPE-00071i-00; Mon, 03 Nov 2003 10:14:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGgPD-00071f-00; Mon, 03 Nov 2003 10:14:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgP3-0002zc-U1; Mon, 03 Nov 2003 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgOM-0002yp-Dc for simple@optimus.ietf.org; Mon, 03 Nov 2003 10:13:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05762 for ; Mon, 3 Nov 2003 10:13:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgOJ-0006zs-00 for simple@ietf.org; Mon, 03 Nov 2003 10:13:15 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AGgOJ-0006yV-00 for simple@ietf.org; Mon, 03 Nov 2003 10:13:15 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA3FCgFN019244; Mon, 3 Nov 2003 07:12:43 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADR08092; Mon, 3 Nov 2003 10:12:42 -0500 (EST) Message-ID: <3FA67069.90405@cisco.com> 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: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 10:12:41 -0500 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > >>>Could you be bit more specific. Do you meant that for example for >>> element XML schema should define the exact structure how >>>method names should be presented? >> >>No. I mean your xml format doesn't cover: >>- negation > > > Correct, this seems to be missing from all string typed attributes. For > boolean types value 'false' can probably be interpreted as negation. Right. Negation is pretty silly for boolean types. So its easy during publication to represent !TRUE as FALSE and visa versa. > There are currently two ways that String types are used: > - enumerated types (like class) > - lists (like methods) > For enumeration types negation is easily added into XML syntax. For > lists this is not that trivial. One option is to add negation as ! mark > into value string like: INVITE, !MESSAGE. Other > alternative would be to redesign these lists bit differently like: > > > INVITE > MESSAGE> > > > Second alternative is bit heavier one but I still think it is the better > one. The first seems more convenient, to read, to generate, and to process. Yet another possibility is to keep the simple types simple and use the general form for anything more complex. > > >>- number ranges > > > Do you mean for 'priority' tag? If yes I can add it to next version. The priority tag is the only one among the base tags. But of course it is also needed for extension tags. >>- distinction between tokens and strings >> (tokens use case-insensitive compare, >> strings use case-sensitive compare) > > > For me it is not clear what is the intended usage of comparison > operations is this context. There are at least two cases: > 1) XML document level comparison > So, in this case two XML documents (or parts if them) are compared > directly. I am not aware of any XML representation which would allow > these type of operations (case insensitive/sensitive) and also I am not > sure if this is relevant case for us. > 2) Element value comparison > In this case you would extract the values of the XML elements and then > compare the extracted values. Here we can do: > - Specify these things in the draft (no XML representation) > - Add new attribute into XML structure like which can > specify if element contains case sensitive or insensitive data. Well, presence publication is analogous to callee-caps. It standardizes nothing analogous to callerprefs - no matching algorithm. Nevertheless, the matching algorithms of callerprefs depend on the syntax of the values to determine case sensitive vs case insensitive matching. The specification of individual features specifies what kinds of values should be used, but the algorithms that process these aren't expected to know those definitions. So it is important to preserve the semantic of whether a particular value is to be compared in a case sensitive or case insensitive way. So I think I agree with your 2nd alternative in (2) above - we need something in the xml structure to indicate this. Because tokens are more frequently used than strings, it probably makes sense for the default to be tokens. Note that string comparison is different than token comparison in another way - commas in strings don't delimit tokens. One more thing - the way numeric values are handled may enter the picture here - they are a third variant. Note that in theory you could write something like: priority="#=5" or priority="5" Both are syntactically correct, but the second is a token rather than a number, and comparison rules are different. It is probably improper usage to mix the two notations for the same parameter value, but a piece of code that doesn't know the particular feature should still understand how to compare. ("#=5" matches "#=005" and "#<=6", but "5" doesn't match "005"). Maybe could do something like: INVITE,OPTIONS,BYE <=3,=5 A string, with comma And then the base types can imply the proper type without having to specify it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 3 10:14:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06003 for ; Mon, 3 Nov 2003 10:14:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgPI-00030k-PT for simple-archive@odin.ietf.org; Mon, 03 Nov 2003 10:14:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3FEGq5011571 for simple-archive@odin.ietf.org; Mon, 3 Nov 2003 10:14:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgPH-00030E-4p for simple-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 10:14:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05917; Mon, 3 Nov 2003 10:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgPE-00071i-00; Mon, 03 Nov 2003 10:14:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGgPD-00071f-00; Mon, 03 Nov 2003 10:14:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgP3-0002zc-U1; Mon, 03 Nov 2003 10:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgOM-0002yp-Dc for simple@optimus.ietf.org; Mon, 03 Nov 2003 10:13:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05762 for ; Mon, 3 Nov 2003 10:13:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgOJ-0006zs-00 for simple@ietf.org; Mon, 03 Nov 2003 10:13:15 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AGgOJ-0006yV-00 for simple@ietf.org; Mon, 03 Nov 2003 10:13:15 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA3FCgFN019244; Mon, 3 Nov 2003 07:12:43 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADR08092; Mon, 3 Nov 2003 10:12:42 -0500 (EST) Message-ID: <3FA67069.90405@cisco.com> 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: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 10:12:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > >>>Could you be bit more specific. Do you meant that for example for >>> element XML schema should define the exact structure how >>>method names should be presented? >> >>No. I mean your xml format doesn't cover: >>- negation > > > Correct, this seems to be missing from all string typed attributes. For > boolean types value 'false' can probably be interpreted as negation. Right. Negation is pretty silly for boolean types. So its easy during publication to represent !TRUE as FALSE and visa versa. > There are currently two ways that String types are used: > - enumerated types (like class) > - lists (like methods) > For enumeration types negation is easily added into XML syntax. For > lists this is not that trivial. One option is to add negation as ! mark > into value string like: INVITE, !MESSAGE. Other > alternative would be to redesign these lists bit differently like: > > > INVITE > MESSAGE> > > > Second alternative is bit heavier one but I still think it is the better > one. The first seems more convenient, to read, to generate, and to process. Yet another possibility is to keep the simple types simple and use the general form for anything more complex. > > >>- number ranges > > > Do you mean for 'priority' tag? If yes I can add it to next version. The priority tag is the only one among the base tags. But of course it is also needed for extension tags. >>- distinction between tokens and strings >> (tokens use case-insensitive compare, >> strings use case-sensitive compare) > > > For me it is not clear what is the intended usage of comparison > operations is this context. There are at least two cases: > 1) XML document level comparison > So, in this case two XML documents (or parts if them) are compared > directly. I am not aware of any XML representation which would allow > these type of operations (case insensitive/sensitive) and also I am not > sure if this is relevant case for us. > 2) Element value comparison > In this case you would extract the values of the XML elements and then > compare the extracted values. Here we can do: > - Specify these things in the draft (no XML representation) > - Add new attribute into XML structure like which can > specify if element contains case sensitive or insensitive data. Well, presence publication is analogous to callee-caps. It standardizes nothing analogous to callerprefs - no matching algorithm. Nevertheless, the matching algorithms of callerprefs depend on the syntax of the values to determine case sensitive vs case insensitive matching. The specification of individual features specifies what kinds of values should be used, but the algorithms that process these aren't expected to know those definitions. So it is important to preserve the semantic of whether a particular value is to be compared in a case sensitive or case insensitive way. So I think I agree with your 2nd alternative in (2) above - we need something in the xml structure to indicate this. Because tokens are more frequently used than strings, it probably makes sense for the default to be tokens. Note that string comparison is different than token comparison in another way - commas in strings don't delimit tokens. One more thing - the way numeric values are handled may enter the picture here - they are a third variant. Note that in theory you could write something like: priority="#=5" or priority="5" Both are syntactically correct, but the second is a token rather than a number, and comparison rules are different. It is probably improper usage to mix the two notations for the same parameter value, but a piece of code that doesn't know the particular feature should still understand how to compare. ("#=5" matches "#=005" and "#<=6", but "5" doesn't match "005"). Maybe could do something like: INVITE,OPTIONS,BYE <=3,=5 A string, with comma And then the base types can imply the proper type without having to specify it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 3 23:21:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14138; Mon, 3 Nov 2003 23:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGshg-0005Eu-00; Mon, 03 Nov 2003 23:22:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGshf-0005Er-00; Mon, 03 Nov 2003 23:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGshd-0005s2-QA; Mon, 03 Nov 2003 23:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsgg-0005iL-Fe for simple@optimus.ietf.org; Mon, 03 Nov 2003 23:21:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14085; Mon, 3 Nov 2003 23:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsge-0005Dv-00; Mon, 03 Nov 2003 23:21:00 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGsgd-0005Dp-00; Mon, 03 Nov 2003 23:20:59 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44KKca010851; Mon, 3 Nov 2003 23:20:21 -0500 (EST) Message-ID: <3FA6FB5B.2000209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> <3FA34FAD.2020500@cs.columbia.edu> In-Reply-To: <3FA34FAD.2020500@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 20:05:31 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > [Starting clean...] > > There are two somewhat separate issues: > > (1) Splitting into domain and user components, i.e., we could have > permissions that apply to all users in a domain and some that apply to > only specific users. That, by itself, does not break the additive model, > if specific users have at least the permissions of the specific users > within the domain. > > While I don't believe that, in practice, domain-specific permissions are > all that useful for organizations of non-trivial size, the model of > "everybody within domain gets baseline permissions, special people get > more" seems plausible. In particular, this seems to be a common cases for many small to medium enterprises, where "domain" is the domain of the enterprise. > (2) I share Hannes concern about making exceptions on any field, > including the user or domain match. I don't see the real-world > motivation for this and it complicates the conceptual model. (In the > geopriv interim we discussed at length as to why blacklists are > generally a bad idea, even with authentication, unless you can guarantee > that the bad guys you want to keep out can't change their verified > identity to a new one.) I think this is a legitimate complaint for the case "accept anyone EXCEPT for Joe". However, for the case "accept anyone from example.com EXCEPT Joe", I dont think this concern is applicable. There, it is not so easy for the user to change their identity to a new one. The classic use case would be a company where I initially allow anyone in my enterprise, but then this one bothersome employee keeps pestering me for information every time I log in, and I want to put him on my black list so he doesnt see my status anymore. This seems like a legitimate case. Also, another case where except clauses make sense is where I want different information provided to different people. For example, everyone in my company sees my cell phone status and my PC status, except for that annoying Joe again, who only sees my PC. My main point, however, is that none of my arguments above are specific to presence as opposed to geopriv. If blacklists are bad for geopriv, they are also bad for presence, and vice a versa. > > At one point, I thought the basic design principle was that we weren't > done until we couldn't *remove* any features - with policies, it's > always tempting to pile on more and more "could be useful somewhere" > items, so I think proponents of particular items should be held to a > fairly high standard of proof as to why a particular feature is > absolutely, positively necessary for a first version. In the geopriv > draft, we spend some time talking about future extensions and how they > are privacy-safe under certain baseline assumptions. We can't anticipate > all the things that we might need and the things that turn out to be > less than useful in practice, so I'd much rather start clean and small > and then expand based on implementation experience. We just don't have a > whole lot (if any) experience with policy languages or rule sets in the > IETF. I am with you on removing features, and as you can see have taken the axe to xcap-auth in a pretty serious way. I am also totally in agreement with the value of something being privacy-safe. I think the concerns about except-clauses in the applies-to section only apply when the except-clauses reference external lists. I see several options there: (1) don't allow except clauses to reference external lists at all (2) allow them to reference lists present only on the same server (3) AND/OR if the list cannot be obtained, then the permissions in the associated statement are granted to NO ONE. I believe that (1), (2,3) or (3) would make the except clause privacy safe. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 3 23:22:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14177 for ; Mon, 3 Nov 2003 23:22:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGshi-0005vk-Q8 for simple-archive@odin.ietf.org; Mon, 03 Nov 2003 23:22:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA44M6W7022795 for simple-archive@odin.ietf.org; Mon, 3 Nov 2003 23:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGshi-0005vX-N1 for simple-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 23:22:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14138; Mon, 3 Nov 2003 23:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGshg-0005Eu-00; Mon, 03 Nov 2003 23:22:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGshf-0005Er-00; Mon, 03 Nov 2003 23:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGshd-0005s2-QA; Mon, 03 Nov 2003 23:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsgg-0005iL-Fe for simple@optimus.ietf.org; Mon, 03 Nov 2003 23:21:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14085; Mon, 3 Nov 2003 23:20:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsge-0005Dv-00; Mon, 03 Nov 2003 23:21:00 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGsgd-0005Dp-00; Mon, 03 Nov 2003 23:20:59 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44KKca010851; Mon, 3 Nov 2003 23:20:21 -0500 (EST) Message-ID: <3FA6FB5B.2000209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> <3FA34FAD.2020500@cs.columbia.edu> In-Reply-To: <3FA34FAD.2020500@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 20:05:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > [Starting clean...] > > There are two somewhat separate issues: > > (1) Splitting into domain and user components, i.e., we could have > permissions that apply to all users in a domain and some that apply to > only specific users. That, by itself, does not break the additive model, > if specific users have at least the permissions of the specific users > within the domain. > > While I don't believe that, in practice, domain-specific permissions are > all that useful for organizations of non-trivial size, the model of > "everybody within domain gets baseline permissions, special people get > more" seems plausible. In particular, this seems to be a common cases for many small to medium enterprises, where "domain" is the domain of the enterprise. > (2) I share Hannes concern about making exceptions on any field, > including the user or domain match. I don't see the real-world > motivation for this and it complicates the conceptual model. (In the > geopriv interim we discussed at length as to why blacklists are > generally a bad idea, even with authentication, unless you can guarantee > that the bad guys you want to keep out can't change their verified > identity to a new one.) I think this is a legitimate complaint for the case "accept anyone EXCEPT for Joe". However, for the case "accept anyone from example.com EXCEPT Joe", I dont think this concern is applicable. There, it is not so easy for the user to change their identity to a new one. The classic use case would be a company where I initially allow anyone in my enterprise, but then this one bothersome employee keeps pestering me for information every time I log in, and I want to put him on my black list so he doesnt see my status anymore. This seems like a legitimate case. Also, another case where except clauses make sense is where I want different information provided to different people. For example, everyone in my company sees my cell phone status and my PC status, except for that annoying Joe again, who only sees my PC. My main point, however, is that none of my arguments above are specific to presence as opposed to geopriv. If blacklists are bad for geopriv, they are also bad for presence, and vice a versa. > > At one point, I thought the basic design principle was that we weren't > done until we couldn't *remove* any features - with policies, it's > always tempting to pile on more and more "could be useful somewhere" > items, so I think proponents of particular items should be held to a > fairly high standard of proof as to why a particular feature is > absolutely, positively necessary for a first version. In the geopriv > draft, we spend some time talking about future extensions and how they > are privacy-safe under certain baseline assumptions. We can't anticipate > all the things that we might need and the things that turn out to be > less than useful in practice, so I'd much rather start clean and small > and then expand based on implementation experience. We just don't have a > whole lot (if any) experience with policy languages or rule sets in the > IETF. I am with you on removing features, and as you can see have taken the axe to xcap-auth in a pretty serious way. I am also totally in agreement with the value of something being privacy-safe. I think the concerns about except-clauses in the applies-to section only apply when the except-clauses reference external lists. I see several options there: (1) don't allow except clauses to reference external lists at all (2) allow them to reference lists present only on the same server (3) AND/OR if the list cannot be obtained, then the permissions in the associated statement are granted to NO ONE. I believe that (1), (2,3) or (3) would make the except clause privacy safe. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 3 23:22:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14207; Mon, 3 Nov 2003 23:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsia-0005Fw-00; Mon, 03 Nov 2003 23:23:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGsia-0005Fq-00; Mon, 03 Nov 2003 23:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsib-00061p-09; Mon, 03 Nov 2003 23:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsht-0005xq-TK for simple@optimus.ietf.org; Mon, 03 Nov 2003 23:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14156 for ; Mon, 3 Nov 2003 23:22:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGshr-0005F9-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:15 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGshr-0005EQ-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:15 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44Lbca010888; Mon, 3 Nov 2003 23:21:38 -0500 (EST) Message-ID: <3FA718A0.80408@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> <3FA67069.90405@cisco.com> In-Reply-To: <3FA67069.90405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 22:10:24 -0500 Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > mikko.lonnfors@nokia.com wrote: > >> >>>> Could you be bit more specific. Do you meant that for example for >>>> element XML schema should define the exact structure how >>>> method names should be presented? >>> >>> >>> No. I mean your xml format doesn't cover: >>> - negation >> >> >> >> Correct, this seems to be missing from all string typed attributes. For >> boolean types value 'false' can probably be interpreted as negation. > > > Right. Negation is pretty silly for boolean types. So its easy during > publication to represent !TRUE as FALSE and visa versa. > >> There are currently two ways that String types are used: >> - enumerated types (like class) >> - lists (like methods) >> For enumeration types negation is easily added into XML syntax. For >> lists this is not that trivial. One option is to add negation as ! mark >> into value string like: INVITE, !MESSAGE. Other >> alternative would be to redesign these lists bit differently like: >> >> >> INVITE >> MESSAGE> >> >> Second alternative is bit heavier one but I still think it is the better >> one. > > > The first seems more convenient, to read, to generate, and to process. I prefer the second, actually. Generally, the reason is that it avoids another layer of parsers to be implemented. The callee caps syntax is not a pride point in design; its ugliness needed because of the constraints of encoding the information as header parameters. XML gives you a rich structure. Why bother defining a new syntax for lists within an element, when you can use XML natively to do that? Similarly, I would do negation with an attribute, rather than include the ! within the value. Also, I don't see the need for a methods tag AND a method tag. Why not: INVITE MESSAGE > Well, presence publication is analogous to callee-caps. It standardizes > nothing analogous to callerprefs - no matching algorithm. > > Nevertheless, the matching algorithms of callerprefs depend on the > syntax of the values to determine case sensitive vs case insensitive > matching. The specification of individual features specifies what kinds > of values should be used, but the algorithms that process these aren't > expected to know those definitions. > > So it is important to preserve the semantic of whether a particular > value is to be compared in a case sensitive or case insensitive way. > > So I think I agree with your 2nd alternative in (2) above - we need > something in the xml structure to indicate this. Because tokens are more > frequently used than strings, it probably makes sense for the default to > be tokens. I would rather propose that you have this as part of the xml element itself, and so instead of using "other-tag", instead have "token", "string", "range" etc. as elements: INVITE Foobar ball > > Note that string comparison is different than token comparison in > another way - commas in strings don't delimit tokens. > > One more thing - the way numeric values are handled may enter the > picture here - they are a third variant. Note that in theory you could > write something like: > > priority="#=5" > or > priority="5" > > Both are syntactically correct, but the second is a token rather than a > number, and comparison rules are different. It is probably improper > usage to mix the two notations for the same parameter value, but a piece > of code that doesn't know the particular feature should still understand > how to compare. > > ("#=5" matches "#=005" and "#<=6", but "5" doesn't match "005"). > > Maybe could do something like: > > > INVITE,OPTIONS,BYE > > <=3,=5 > > A string, with comma > I would prefer: to the range syntax above. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 3 23:23:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14242 for ; Mon, 3 Nov 2003 23:23:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsid-00066J-5A for simple-archive@odin.ietf.org; Mon, 03 Nov 2003 23:23:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA44N3p6023444 for simple-archive@odin.ietf.org; Mon, 3 Nov 2003 23:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsid-000663-0K for simple-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 23:23:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14205; Mon, 3 Nov 2003 23:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsia-0005Ft-00; Mon, 03 Nov 2003 23:23:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGsiZ-0005Fp-00; Mon, 03 Nov 2003 23:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsia-00061V-HY; Mon, 03 Nov 2003 23:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGshf-0005su-Mw for simple@optimus.ietf.org; Mon, 03 Nov 2003 23:22:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14134 for ; Mon, 3 Nov 2003 23:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGshd-0005Eo-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:01 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGshd-0005EO-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:01 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44LIca010885; Mon, 3 Nov 2003 23:21:31 -0500 (EST) Message-ID: <3FA714FB.1030301@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Event Notification Filtering Drafts References: <2038BCC78B1AD641891A0D1AE133DBB701797342@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797342@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 21:54:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, Thanks for your continued work on this. A few comments. Firstly, the filter format seems quite complicated. It is very rich, allowing for conditional inclusions, inclusion by namespace and element names, triggers of various kinds, inclusions and exclusions, and level filtering. As we did with xcap-auth, I wonder if we should scale this back a bit, and start small. Instead, focus on the real must-haves that are needed today, and ensure that there is sufficient extensibility to add some of the other stuff later. Secondly, you have defined your own xpath-type syntax. Interestingly, I did a similar thing in the xcap spec. Your syntax covers a superset of the functionality I am providing. Can we get away with just one format? Indeed, depending on the scope there may not be a need for xpath style expressions at all. I booted them out of xcap-auth, in fact. i've backed down from the position that they don't make sense in a filter; I think they do. However, there is still a question if they are needed at all. It seems that the filter format could cause the presence server to create presence documents that are not schema compliant. That shoudnt be allowed. Unfortunately, its not clear that this could be known at the time the filter is uploaded. How do we deal with error handling in this case? One option is to reduce the scope to make sure that the filters cannot cause the server to create presence documents that arent schema compliant. There could be some potential for confusion around namespaces. You need to allow for addressing of elements using fully qualified names (i.e., prefix:local-name). In this case, is the prefix the one defined in the filter document, or in the presence document? FOr example: filter: foo:class="IM" or rpid:class="SMS" or rpid:class="MMS" //tuple //tuple //tuple and presence document: SMS open I believe that the prefix is purely local to the XML document in which its defined, in whcih case the filter would remove the class element in the presence document above. But, you probably want to clearly define the matching operations to make sure this is so. The namespaces specification has some text on canonicalization which can probably help. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > An update to the Event Notification Filtering solutions is now available. > > The XML format is defined in: > http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-format-01.txt > > The functionality draft is defined in: > http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-01.txt > > One major change in the format draft is that we removed the xpath expression and defined a trimmed down version suitable for the filtering solution needs. The functionality draft changes were minor. > > The requirements drafts can be found behind the following links: > http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt > > There has been no update to the requirements document due to lack of comments. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 3 23:23:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14257 for ; Mon, 3 Nov 2003 23:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsie-000677-Kg for simple-archive@odin.ietf.org; Mon, 03 Nov 2003 23:23:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA44N4qQ023495 for simple-archive@odin.ietf.org; Mon, 3 Nov 2003 23:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsie-00066A-HI for simple-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 23:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14207; Mon, 3 Nov 2003 23:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsia-0005Fw-00; Mon, 03 Nov 2003 23:23:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGsia-0005Fq-00; Mon, 03 Nov 2003 23:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsib-00061p-09; Mon, 03 Nov 2003 23:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsht-0005xq-TK for simple@optimus.ietf.org; Mon, 03 Nov 2003 23:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14156 for ; Mon, 3 Nov 2003 23:22:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGshr-0005F9-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:15 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGshr-0005EQ-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:15 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44Lbca010888; Mon, 3 Nov 2003 23:21:38 -0500 (EST) Message-ID: <3FA718A0.80408@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> <3FA67069.90405@cisco.com> In-Reply-To: <3FA67069.90405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 22:10:24 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > > > mikko.lonnfors@nokia.com wrote: > >> >>>> Could you be bit more specific. Do you meant that for example for >>>> element XML schema should define the exact structure how >>>> method names should be presented? >>> >>> >>> No. I mean your xml format doesn't cover: >>> - negation >> >> >> >> Correct, this seems to be missing from all string typed attributes. For >> boolean types value 'false' can probably be interpreted as negation. > > > Right. Negation is pretty silly for boolean types. So its easy during > publication to represent !TRUE as FALSE and visa versa. > >> There are currently two ways that String types are used: >> - enumerated types (like class) >> - lists (like methods) >> For enumeration types negation is easily added into XML syntax. For >> lists this is not that trivial. One option is to add negation as ! mark >> into value string like: INVITE, !MESSAGE. Other >> alternative would be to redesign these lists bit differently like: >> >> >> INVITE >> MESSAGE> >> >> Second alternative is bit heavier one but I still think it is the better >> one. > > > The first seems more convenient, to read, to generate, and to process. I prefer the second, actually. Generally, the reason is that it avoids another layer of parsers to be implemented. The callee caps syntax is not a pride point in design; its ugliness needed because of the constraints of encoding the information as header parameters. XML gives you a rich structure. Why bother defining a new syntax for lists within an element, when you can use XML natively to do that? Similarly, I would do negation with an attribute, rather than include the ! within the value. Also, I don't see the need for a methods tag AND a method tag. Why not: INVITE MESSAGE > Well, presence publication is analogous to callee-caps. It standardizes > nothing analogous to callerprefs - no matching algorithm. > > Nevertheless, the matching algorithms of callerprefs depend on the > syntax of the values to determine case sensitive vs case insensitive > matching. The specification of individual features specifies what kinds > of values should be used, but the algorithms that process these aren't > expected to know those definitions. > > So it is important to preserve the semantic of whether a particular > value is to be compared in a case sensitive or case insensitive way. > > So I think I agree with your 2nd alternative in (2) above - we need > something in the xml structure to indicate this. Because tokens are more > frequently used than strings, it probably makes sense for the default to > be tokens. I would rather propose that you have this as part of the xml element itself, and so instead of using "other-tag", instead have "token", "string", "range" etc. as elements: INVITE Foobar ball > > Note that string comparison is different than token comparison in > another way - commas in strings don't delimit tokens. > > One more thing - the way numeric values are handled may enter the > picture here - they are a third variant. Note that in theory you could > write something like: > > priority="#=5" > or > priority="5" > > Both are syntactically correct, but the second is a token rather than a > number, and comparison rules are different. It is probably improper > usage to mix the two notations for the same parameter value, but a piece > of code that doesn't know the particular feature should still understand > how to compare. > > ("#=5" matches "#=005" and "#<=6", but "5" doesn't match "005"). > > Maybe could do something like: > > > INVITE,OPTIONS,BYE > > <=3,=5 > > A string, with comma > I would prefer: to the range syntax above. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 00:10:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14205; Mon, 3 Nov 2003 23:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGsia-0005Ft-00; Mon, 03 Nov 2003 23:23:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGsiZ-0005Fp-00; Mon, 03 Nov 2003 23:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGsia-00061V-HY; Mon, 03 Nov 2003 23:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGshf-0005su-Mw for simple@optimus.ietf.org; Mon, 03 Nov 2003 23:22:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14134 for ; Mon, 3 Nov 2003 23:21:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGshd-0005Eo-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:01 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGshd-0005EO-00 for simple@ietf.org; Mon, 03 Nov 2003 23:22:01 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA44LIca010885; Mon, 3 Nov 2003 23:21:31 -0500 (EST) Message-ID: <3FA714FB.1030301@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Event Notification Filtering Drafts References: <2038BCC78B1AD641891A0D1AE133DBB701797342@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797342@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 03 Nov 2003 21:54:51 -0500 Content-Transfer-Encoding: 7bit Hisham, Thanks for your continued work on this. A few comments. Firstly, the filter format seems quite complicated. It is very rich, allowing for conditional inclusions, inclusion by namespace and element names, triggers of various kinds, inclusions and exclusions, and level filtering. As we did with xcap-auth, I wonder if we should scale this back a bit, and start small. Instead, focus on the real must-haves that are needed today, and ensure that there is sufficient extensibility to add some of the other stuff later. Secondly, you have defined your own xpath-type syntax. Interestingly, I did a similar thing in the xcap spec. Your syntax covers a superset of the functionality I am providing. Can we get away with just one format? Indeed, depending on the scope there may not be a need for xpath style expressions at all. I booted them out of xcap-auth, in fact. i've backed down from the position that they don't make sense in a filter; I think they do. However, there is still a question if they are needed at all. It seems that the filter format could cause the presence server to create presence documents that are not schema compliant. That shoudnt be allowed. Unfortunately, its not clear that this could be known at the time the filter is uploaded. How do we deal with error handling in this case? One option is to reduce the scope to make sure that the filters cannot cause the server to create presence documents that arent schema compliant. There could be some potential for confusion around namespaces. You need to allow for addressing of elements using fully qualified names (i.e., prefix:local-name). In this case, is the prefix the one defined in the filter document, or in the presence document? FOr example: filter: foo:class="IM" or rpid:class="SMS" or rpid:class="MMS" //tuple //tuple //tuple and presence document: SMS open I believe that the prefix is purely local to the XML document in which its defined, in whcih case the filter would remove the class element in the presence document above. But, you probably want to clearly define the matching operations to make sure this is so. The namespaces specification has some text on canonicalization which can probably help. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > An update to the Event Notification Filtering solutions is now available. > > The XML format is defined in: > http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-format-01.txt > > The functionality draft is defined in: > http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-01.txt > > One major change in the format draft is that we removed the xpath expression and defined a trimmed down version suitable for the filtering solution needs. The functionality draft changes were minor. > > The requirements drafts can be found behind the following links: > http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt > > There has been no update to the requirements document due to lack of comments. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 08:36:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14039; Tue, 4 Nov 2003 08:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Lw-0005Xq-00; Tue, 04 Nov 2003 08:36:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH1Lv-0005Xl-00; Tue, 04 Nov 2003 08:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Lm-0005fo-Bu; Tue, 04 Nov 2003 08:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1LV-0005fN-Rx for simple@optimus.ietf.org; Tue, 04 Nov 2003 08:35:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14030 for ; Tue, 4 Nov 2003 08:35:33 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1LU-0005Xc-00 for simple@ietf.org; Tue, 04 Nov 2003 08:35:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AH1LT-0005XZ-00 for simple@ietf.org; Tue, 04 Nov 2003 08:35:43 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4DZfY07896 for ; Tue, 4 Nov 2003 15:35:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Nov 2003 15:35:40 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 15:35:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD8@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Thread-Index: AcOii188T9hBAGTGTUa8lIg5XIgmVQAHMSZQ To: , Cc: X-OriginalArrivalTime: 04 Nov 2003 13:35:41.0009 (UTC) FILETIME=[8A19D410:01C3A2D8] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 15:35:40 +0200 Content-Transfer-Encoding: quoted-printable Hi, Inline > >> lists this is not that trivial. One option is to add negation as ! > >> mark into value string like: INVITE, !MESSAGE.=20 > >> Other alternative would be to redesign these lists bit differently=20 > >> like: > >> > >> > >> INVITE > >> MESSAGE> > >> > >> Second alternative is bit heavier one but I still think it is the > >> better one. > >=20 > >=20 > > The first seems more convenient, to read, to generate, and > to process. >=20 > I prefer the second, actually. Generally, the reason is that > it avoids=20 > another layer of parsers to be implemented. The callee caps syntax is=20 > not a pride point in design; its ugliness needed because of the=20 > constraints of encoding the information as header parameters. XML=20 > gives you a rich structure. Why bother defining a new syntax=20 > for lists=20 > within an element, when you can use XML natively to do that?=20 > Similarly, I would do negation with an attribute, rather than include=20 > the ! within the value. Also, I don't see the need for a methods tag=20 > AND a method tag. Why not: >=20 > INVITE > MESSAGE I would also go for second option basically with same reasoning what Jonathan provided.=20 Initial idea in using both and was to collect all elements into a single place. Probably this isn't needed so for my part can go. =20 > >=20 > > So it is important to preserve the semantic of whether a particular=20 > > value is to be compared in a case sensitive or case insensitive way. > >=20 > > So I think I agree with your 2nd alternative in (2) above - we need=20 > > something in the xml structure to indicate this. Because > tokens are more > > frequently used than strings, it probably makes sense for > the default to > > be tokens. >=20 > I would rather propose that you have this as part of the xml element > itself, and so instead of using "other-tag", instead have "token",=20 > "string", "range" etc. as elements: >=20 > INVITE > Foobar > ball Yes, why not. So what is the full list of types which would be needed? I can come up with: token, string, range, integer and boolean. Are there any others? =20 > >=20 > > Note that string comparison is different than token comparison in=20 > > another way - commas in strings don't delimit tokens. > >=20 > > One more thing - the way numeric values are handled may enter the=20 > > picture here - they are a third variant. Note that in > theory you could > > write something like: > >=20 > > priority=3D"#=3D5" > > or > > priority=3D"5" > >=20 > > Both are syntactically correct, but the second is a token > rather than > > a > > number, and comparison rules are different. It is probably improper > > usage to mix the two notations for the same parameter=20 > value, but a piece > > of code that doesn't know the particular feature should > still understand > > how to compare. > >=20 > > ("#=3D5" matches "#=3D005" and "#<=3D6", but "5" doesn't match = "005"). > >=20 > > Maybe could do something like: > >=20 > > > > INVITE,OPTIONS,BYE > > > > <=3D3,=3D5 > > > > A string, with comma > >=20 >=20 > I would prefer: >=20 > > >=20 > to the range syntax above. Do you mean that 'less-than-or-equal-to' and 'equal' would be parameters and there would not be any value for element? This probably can be done but it seems to be bit inconsistent with proposed and elements. How about if attributes (like equal) would be defined as boolean attributes and then the value would be places inside element like: =20 5 - Mikko > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 08:36:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14062 for ; Tue, 4 Nov 2003 08:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Ly-0005gl-25 for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 08:36:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4DaExD021863 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 08:36:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Lx-0005gY-UU for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 08:36:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14039; Tue, 4 Nov 2003 08:36:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1Lw-0005Xq-00; Tue, 04 Nov 2003 08:36:12 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH1Lv-0005Xl-00; Tue, 04 Nov 2003 08:36:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1Lm-0005fo-Bu; Tue, 04 Nov 2003 08:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH1LV-0005fN-Rx for simple@optimus.ietf.org; Tue, 04 Nov 2003 08:35:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14030 for ; Tue, 4 Nov 2003 08:35:33 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH1LU-0005Xc-00 for simple@ietf.org; Tue, 04 Nov 2003 08:35:44 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AH1LT-0005XZ-00 for simple@ietf.org; Tue, 04 Nov 2003 08:35:43 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4DZfY07896 for ; Tue, 4 Nov 2003 15:35:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 4 Nov 2003 15:35:40 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 15:35:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD8@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 Thread-Index: AcOii188T9hBAGTGTUa8lIg5XIgmVQAHMSZQ To: , Cc: X-OriginalArrivalTime: 04 Nov 2003 13:35:41.0009 (UTC) FILETIME=[8A19D410:01C3A2D8] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 15:35:40 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Inline > >> lists this is not that trivial. One option is to add negation as ! > >> mark into value string like: INVITE, !MESSAGE.=20 > >> Other alternative would be to redesign these lists bit differently=20 > >> like: > >> > >> > >> INVITE > >> MESSAGE> > >> > >> Second alternative is bit heavier one but I still think it is the > >> better one. > >=20 > >=20 > > The first seems more convenient, to read, to generate, and > to process. >=20 > I prefer the second, actually. Generally, the reason is that > it avoids=20 > another layer of parsers to be implemented. The callee caps syntax is=20 > not a pride point in design; its ugliness needed because of the=20 > constraints of encoding the information as header parameters. XML=20 > gives you a rich structure. Why bother defining a new syntax=20 > for lists=20 > within an element, when you can use XML natively to do that?=20 > Similarly, I would do negation with an attribute, rather than include=20 > the ! within the value. Also, I don't see the need for a methods tag=20 > AND a method tag. Why not: >=20 > INVITE > MESSAGE I would also go for second option basically with same reasoning what Jonathan provided.=20 Initial idea in using both and was to collect all elements into a single place. Probably this isn't needed so for my part can go. =20 > >=20 > > So it is important to preserve the semantic of whether a particular=20 > > value is to be compared in a case sensitive or case insensitive way. > >=20 > > So I think I agree with your 2nd alternative in (2) above - we need=20 > > something in the xml structure to indicate this. Because > tokens are more > > frequently used than strings, it probably makes sense for > the default to > > be tokens. >=20 > I would rather propose that you have this as part of the xml element > itself, and so instead of using "other-tag", instead have "token",=20 > "string", "range" etc. as elements: >=20 > INVITE > Foobar > ball Yes, why not. So what is the full list of types which would be needed? I can come up with: token, string, range, integer and boolean. Are there any others? =20 > >=20 > > Note that string comparison is different than token comparison in=20 > > another way - commas in strings don't delimit tokens. > >=20 > > One more thing - the way numeric values are handled may enter the=20 > > picture here - they are a third variant. Note that in > theory you could > > write something like: > >=20 > > priority=3D"#=3D5" > > or > > priority=3D"5" > >=20 > > Both are syntactically correct, but the second is a token > rather than > > a > > number, and comparison rules are different. It is probably improper > > usage to mix the two notations for the same parameter=20 > value, but a piece > > of code that doesn't know the particular feature should > still understand > > how to compare. > >=20 > > ("#=3D5" matches "#=3D005" and "#<=3D6", but "5" doesn't match = "005"). > >=20 > > Maybe could do something like: > >=20 > > > > INVITE,OPTIONS,BYE > > > > <=3D3,=3D5 > > > > A string, with comma > >=20 >=20 > I would prefer: >=20 > > >=20 > to the range syntax above. Do you mean that 'less-than-or-equal-to' and 'equal' would be parameters and there would not be any value for element? This probably can be done but it seems to be bit inconsistent with proposed and elements. How about if attributes (like equal) would be defined as boolean attributes and then the value would be places inside element like: =20 5 - Mikko > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 09:23:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15571; Tue, 4 Nov 2003 09:23:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH25Z-0006DK-00; Tue, 04 Nov 2003 09:23:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH25Y-0006DH-00; Tue, 04 Nov 2003 09:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH25F-00005U-CD; Tue, 04 Nov 2003 09:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH24I-0008Us-0q for simple@optimus.ietf.org; Tue, 04 Nov 2003 09:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15548 for ; Tue, 4 Nov 2003 09:21:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH24G-0006Cc-00 for simple@ietf.org; Tue, 04 Nov 2003 09:22:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AH24F-0006CU-00 for simple@ietf.org; Tue, 04 Nov 2003 09:21:59 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4ELwY08736 for ; Tue, 4 Nov 2003 16:21:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 16:21:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:21:41 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Nov 2003 16:21:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797375@esebe019.ntc.nokia.com> Thread-Topic: Comments on xcap-01 Thread-Index: AcOi3veFEvxHg5VAQ0aTKswFg9hUeg== To: X-OriginalArrivalTime: 04 Nov 2003 14:21:41.0670 (UTC) FILETIME=[F7954460:01C3A2DE] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on xcap-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 16:21:41 +0200 Content-Transfer-Encoding: quoted-printable Overall, I think the document is ready. Some minor comments: - Resource Interdependency: After a server has populated a element or = attribute, like the URI for a list, how does this information get = communicated to the client (how does the client learn of such = information)? Does the server fill it in before the 200 Ok is returned = and body of the response contains the xml document (I don't think this = is a good solution)? - Creating a new document: must the document have file type of .xml? In = the example in section 6.1, should mybuddies be mybuddies.xml? - Content-type: I think defining a content-type for xcap is needed for = creating/replacing elements and attributes. It is better than using = text/plain as currently shown in the examples. - Replacing an element/attribute: It might be useful to indicate that = modifying an element value of an element is not possible, especially if = that element has attributes. The whole element, including its attributes = must be replaced. - E-tags: If an element or attribute has been replaced or deleted, how = does a client learn of such change? A client can never learn of a change = unless is performs a GET and examines the etag. BTW, whatever happened = to the event package for xcap? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 09:23:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15589 for ; Tue, 4 Nov 2003 09:23:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH25b-00007r-Iz for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 09:23:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4ENNnY000477 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 09:23:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH25b-00007c-FS for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 09:23:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15571; Tue, 4 Nov 2003 09:23:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH25Z-0006DK-00; Tue, 04 Nov 2003 09:23:21 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH25Y-0006DH-00; Tue, 04 Nov 2003 09:23:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH25F-00005U-CD; Tue, 04 Nov 2003 09:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH24I-0008Us-0q for simple@optimus.ietf.org; Tue, 04 Nov 2003 09:22:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15548 for ; Tue, 4 Nov 2003 09:21:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH24G-0006Cc-00 for simple@ietf.org; Tue, 04 Nov 2003 09:22:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AH24F-0006CU-00 for simple@ietf.org; Tue, 04 Nov 2003 09:21:59 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4ELwY08736 for ; Tue, 4 Nov 2003 16:21:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 16:21:57 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:21:41 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Nov 2003 16:21:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797375@esebe019.ntc.nokia.com> Thread-Topic: Comments on xcap-01 Thread-Index: AcOi3veFEvxHg5VAQ0aTKswFg9hUeg== To: X-OriginalArrivalTime: 04 Nov 2003 14:21:41.0670 (UTC) FILETIME=[F7954460:01C3A2DE] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on xcap-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 16:21:41 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Overall, I think the document is ready. Some minor comments: - Resource Interdependency: After a server has populated a element or = attribute, like the URI for a list, how does this information get = communicated to the client (how does the client learn of such = information)? Does the server fill it in before the 200 Ok is returned = and body of the response contains the xml document (I don't think this = is a good solution)? - Creating a new document: must the document have file type of .xml? In = the example in section 6.1, should mybuddies be mybuddies.xml? - Content-type: I think defining a content-type for xcap is needed for = creating/replacing elements and attributes. It is better than using = text/plain as currently shown in the examples. - Replacing an element/attribute: It might be useful to indicate that = modifying an element value of an element is not possible, especially if = that element has attributes. The whole element, including its attributes = must be replaced. - E-tags: If an element or attribute has been replaced or deleted, how = does a client learn of such change? A client can never learn of a change = unless is performs a GET and examines the etag. BTW, whatever happened = to the event package for xcap? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 09:23:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15608; Tue, 4 Nov 2003 09:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH26F-0006Dg-00; Tue, 04 Nov 2003 09:24:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH26E-0006Dd-00; Tue, 04 Nov 2003 09:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH26D-0000Ab-FR; Tue, 04 Nov 2003 09:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH268-0000AM-Tl for simple@optimus.ietf.org; Tue, 04 Nov 2003 09:23:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15605 for ; Tue, 4 Nov 2003 09:23:44 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH267-0006DY-00 for simple@ietf.org; Tue, 04 Nov 2003 09:23:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AH266-0006DV-00 for simple@ietf.org; Tue, 04 Nov 2003 09:23:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4ENqF19557 for ; Tue, 4 Nov 2003 16:23:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 16:23:52 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:23:51 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Nov 2003 16:23:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797377@esebe019.ntc.nokia.com> Thread-Topic: Comments on xcap-auth-usage-01 Thread-Index: AcOi30UGqRLXh4GBTIK0zsVFtt/21g== To: X-OriginalArrivalTime: 04 Nov 2003 14:23:51.0648 (UTC) FILETIME=[450E5600:01C3A2DF] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on xcap-auth-usage-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 16:23:51 +0200 Content-Transfer-Encoding: quoted-printable - The introduction talks about how the authorisation decision includes = decisions on "when" the watcher receives notifications. But nothing in = the rest of the text shows how. Is this left over from the last version? - The element says that the statement applies to all users on = the specified presence list. What about sub-lists?=20 Also, what if a resource in a list points to another list? How does the = server learn about the resources in those lists so that it can apply the = authorisation permission to them as well? - The following example is certainly valid: sip:joe@example.com sip:joe@example.com Joe is included then excepted. Should that be forbidden? or it can be = allowed but results in a no-op? The same applies to and = - Why is the id attribute in and needed? isn't = the values of the elements themselves unique enough? - Section 4.2.2 second bullet has "(based on the rule permissions)". = What are the rule permission? - show-note element: a tuple can have multiple elements. Which = one does the select? the first one? all? - encrypt: This permission does not fit with the rest, and is really not = a permission. I can't think at the moment of a place in the xml document = where you can place it. As an attribute in the element is = one idea. - Section 5 and 5.6 mention compound permissions still. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 09:24:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15639 for ; Tue, 4 Nov 2003 09:24:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH26H-0000Cy-AZ for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 09:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4EO5rX000794 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 09:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH26H-0000Cj-6W for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 09:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15608; Tue, 4 Nov 2003 09:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH26F-0006Dg-00; Tue, 04 Nov 2003 09:24:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH26E-0006Dd-00; Tue, 04 Nov 2003 09:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH26D-0000Ab-FR; Tue, 04 Nov 2003 09:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH268-0000AM-Tl for simple@optimus.ietf.org; Tue, 04 Nov 2003 09:23:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15605 for ; Tue, 4 Nov 2003 09:23:44 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH267-0006DY-00 for simple@ietf.org; Tue, 04 Nov 2003 09:23:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AH266-0006DV-00 for simple@ietf.org; Tue, 04 Nov 2003 09:23:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4ENqF19557 for ; Tue, 4 Nov 2003 16:23:52 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 16:23:52 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:23:51 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 4 Nov 2003 16:23:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797377@esebe019.ntc.nokia.com> Thread-Topic: Comments on xcap-auth-usage-01 Thread-Index: AcOi30UGqRLXh4GBTIK0zsVFtt/21g== To: X-OriginalArrivalTime: 04 Nov 2003 14:23:51.0648 (UTC) FILETIME=[450E5600:01C3A2DF] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on xcap-auth-usage-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 16:23:51 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable - The introduction talks about how the authorisation decision includes = decisions on "when" the watcher receives notifications. But nothing in = the rest of the text shows how. Is this left over from the last version? - The element says that the statement applies to all users on = the specified presence list. What about sub-lists?=20 Also, what if a resource in a list points to another list? How does the = server learn about the resources in those lists so that it can apply the = authorisation permission to them as well? - The following example is certainly valid: sip:joe@example.com sip:joe@example.com Joe is included then excepted. Should that be forbidden? or it can be = allowed but results in a no-op? The same applies to and = - Why is the id attribute in and needed? isn't = the values of the elements themselves unique enough? - Section 4.2.2 second bullet has "(based on the rule permissions)". = What are the rule permission? - show-note element: a tuple can have multiple elements. Which = one does the select? the first one? all? - encrypt: This permission does not fit with the rest, and is really not = a permission. I can't think at the moment of a place in the xml document = where you can place it. As an attribute in the element is = one idea. - Section 5 and 5.6 mention compound permissions still. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 09:24:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15657; Tue, 4 Nov 2003 09:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH27E-0006EV-00; Tue, 04 Nov 2003 09:25:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH27E-0006ES-00; Tue, 04 Nov 2003 09:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH27B-0000Gg-M7; Tue, 04 Nov 2003 09:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH26k-0000D5-Fd for simple@optimus.ietf.org; Tue, 04 Nov 2003 09:24:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15637 for ; Tue, 4 Nov 2003 09:24:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH26i-0006EI-00 for simple@ietf.org; Tue, 04 Nov 2003 09:24:32 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AH26i-0006EF-00 for simple@ietf.org; Tue, 04 Nov 2003 09:24:32 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4EOVF20414 for ; Tue, 4 Nov 2003 16:24:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 16:24:31 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797378@esebe019.ntc.nokia.com> Thread-Topic: Comments on xcap-list-usage Thread-Index: AcOi31x3ciAUP/KUSCO0Y6wjEPzDIA== To: X-OriginalArrivalTime: 04 Nov 2003 14:24:31.0140 (UTC) FILETIME=[5C985640:01C3A2DF] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on xcap-list-usage Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 16:24:30 +0200 Content-Transfer-Encoding: quoted-printable - Subscribeable: by whom? Who is authorised to subscribe to this list, = besides the creator of the list? How that indicated? - If the "uri" attribute is absent in a document, but the = "subscribeable" flag is set to true. the XCAP server must allocate a = URI. But what if the URI is present but conflicts with an already = existing URI? How does the server react? Does it reject the request or = does it just rewrite the URI? - Why does the URI need to be globally unique? Can it be unique per user = (i.e. a user can't create 2 lists with the same URI)? we all have = friends@company.com. I guess the answer to this depends on the answer to = the first question: If only the creator can subscribe to the list, then = the URIs can be unique to that user only. The server asserts the user = and then know that he is subscribing to his friends@company.com. This = would not work if multiple users can subscribe to my list. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 09:25:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15690 for ; Tue, 4 Nov 2003 09:25:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH27H-0000IY-6B for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 09:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4EP7Yh001140 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 09:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH27H-0000IJ-2x for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 09:25:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15657; Tue, 4 Nov 2003 09:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH27E-0006EV-00; Tue, 04 Nov 2003 09:25:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH27E-0006ES-00; Tue, 04 Nov 2003 09:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH27B-0000Gg-M7; Tue, 04 Nov 2003 09:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH26k-0000D5-Fd for simple@optimus.ietf.org; Tue, 04 Nov 2003 09:24:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15637 for ; Tue, 4 Nov 2003 09:24:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH26i-0006EI-00 for simple@ietf.org; Tue, 04 Nov 2003 09:24:32 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AH26i-0006EF-00 for simple@ietf.org; Tue, 04 Nov 2003 09:24:32 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA4EOVF20414 for ; Tue, 4 Nov 2003 16:24:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 16:24:31 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 16:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797378@esebe019.ntc.nokia.com> Thread-Topic: Comments on xcap-list-usage Thread-Index: AcOi31x3ciAUP/KUSCO0Y6wjEPzDIA== To: X-OriginalArrivalTime: 04 Nov 2003 14:24:31.0140 (UTC) FILETIME=[5C985640:01C3A2DF] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on xcap-list-usage Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 4 Nov 2003 16:24:30 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable - Subscribeable: by whom? Who is authorised to subscribe to this list, = besides the creator of the list? How that indicated? - If the "uri" attribute is absent in a document, but the = "subscribeable" flag is set to true. the XCAP server must allocate a = URI. But what if the URI is present but conflicts with an already = existing URI? How does the server react? Does it reject the request or = does it just rewrite the URI? - Why does the URI need to be globally unique? Can it be unique per user = (i.e. a user can't create 2 lists with the same URI)? we all have = friends@company.com. I guess the answer to this depends on the answer to = the first question: If only the creator can subscribe to the list, then = the URIs can be unique to that user only. The server asserts the user = and then know that he is subscribing to his friends@company.com. This = would not work if multiple users can subscribe to my list. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 15:20:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03470; Tue, 4 Nov 2003 15:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7fm-0004YZ-00; Tue, 04 Nov 2003 15:21:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH7fl-0004YW-00; Tue, 04 Nov 2003 15:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7fi-0001oB-Hn; Tue, 04 Nov 2003 15:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7fZ-0001nT-V7 for simple@optimus.ietf.org; Tue, 04 Nov 2003 15:20:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03446 for ; Tue, 4 Nov 2003 15:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7fY-0004Y3-00 for simple@ietf.org; Tue, 04 Nov 2003 15:20:52 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AH7fY-0004XR-00 for simple@ietf.org; Tue, 04 Nov 2003 15:20:52 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2003 12:20:41 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA4KKGAx009917; Tue, 4 Nov 2003 12:20:19 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS32063; Tue, 4 Nov 2003 15:20:15 -0500 (EST) Message-ID: <3FA809FF.5010102@cisco.com> 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: Jonathan Rosenberg CC: mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> <3FA67069.90405@cisco.com> <3FA718A0.80408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 15:20:15 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >>> There are currently two ways that String types are used: >>> - enumerated types (like class) >>> - lists (like methods) >>> For enumeration types negation is easily added into XML syntax. For >>> lists this is not that trivial. One option is to add negation as ! mark >>> into value string like: INVITE, !MESSAGE. Other >>> alternative would be to redesign these lists bit differently like: >>> >>> >>> INVITE >>> MESSAGE> >>> >>> Second alternative is bit heavier one but I still think it is the better >>> one. >> >> The first seems more convenient, to read, to generate, and to process. > > I prefer the second, actually. Generally, the reason is that it avoids > another layer of parsers to be implemented. The callee caps syntax is > not a pride point in design; its ugliness needed because of the > constraints of encoding the information as header parameters. XML gives > you a rich structure. Why bother defining a new syntax for lists within > an element, when you can use XML natively to do that? Similarly, I would > do negation with an attribute, rather than include the ! within the > value. I don't feel strongly about this. I agree that the callee caps syntax is nothing to be proud of. But if we don't like that syntax, maybe we should consider simply rerendering the 2533 syntax in xml. Perhaps something like: The description If we aren't going to do that, then we have to make a decision: do we do a syntax rich enough to map to all of 2533, or just to map all of what callee-caps can say, or somewhere in between. (I find it hard to pick someplace in between.) > Also, I don't see the need for a methods tag AND a method tag. > Why not: > > INVITE > MESSAGE Note that this approach does start to become wordy: INVITE OPTIONS BYE UPDATE PRACK SUBSCRIBE NOTIFY PUBLISH rather than: INVITE,OPTIONS,BYE,UPDATE,PRACK,SUBSCRIBE,NOTIFY,PUBLISH It also introduces a semantic issue: SUBSCRIBE NOTIFY means something quite different semantically in terms of matching algorithms than does: SUBSCRIBE presence even though syntactically they are very similar. One should result in a disjunction and the other in a conjunction. This can be dealt with via explanation text - that things corresponding to the same feature tag should first be combined into a disjunction, and then the results combined into a conjunction. But it would be clearer if the syntax was closer to the semantics. >> Well, presence publication is analogous to callee-caps. It >> standardizes nothing analogous to callerprefs - no matching algorithm. >> >> Nevertheless, the matching algorithms of callerprefs depend on the >> syntax of the values to determine case sensitive vs case insensitive >> matching. The specification of individual features specifies what >> kinds of values should be used, but the algorithms that process these >> aren't expected to know those definitions. >> >> So it is important to preserve the semantic of whether a particular >> value is to be compared in a case sensitive or case insensitive way. >> >> So I think I agree with your 2nd alternative in (2) above - we need >> something in the xml structure to indicate this. Because tokens are >> more frequently used than strings, it probably makes sense for the >> default to be tokens. > > I would rather propose that you have this as part of the xml element > itself, and so instead of using "other-tag", instead have "token", > "string", "range" etc. as elements: > > INVITE > Foobar > ball Hadn't thought of that. I sort of like the approach. >> Maybe could do something like: >> >> >> INVITE,OPTIONS,BYE >> >> <=3,=5 >> >> A string, with comma >> > > I would prefer: > > > Are you competing to be champion of verbosity? :-) There is also negation to deal with here. Could do: or Namely, just expand the list of relational operations to be complete: eq, ne, gt, ge, lt, le so that negation isn't needed. That also can be used to cover true ranges too. E.g. priority="#3:5" could be: It isn't needed for booleans or strings either, so then we only need to support negation for tokens. As it happens, the way negation is defined in callee-caps, negation with tokens only makes sense in one very limited case - a single negated token. Any other case is degenerate: - methods="!PRACK,!UPDATE" matches PRACK, UPDATE, and everything else - methods="!PRACK,INVITE" is same as methods="!PRACK" Having talked thru all this, I think I am inclined to seek something semantically equivalent to the 2533 syntax, while perhaps being more concise than a literal transformation. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 15:21:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03498 for ; Tue, 4 Nov 2003 15:21:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7fo-0001pA-Bt for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 15:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4KL8v4007008 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 15:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7fo-0001ox-71 for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 15:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03470; Tue, 4 Nov 2003 15:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7fm-0004YZ-00; Tue, 04 Nov 2003 15:21:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH7fl-0004YW-00; Tue, 04 Nov 2003 15:21:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7fi-0001oB-Hn; Tue, 04 Nov 2003 15:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH7fZ-0001nT-V7 for simple@optimus.ietf.org; Tue, 04 Nov 2003 15:20:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03446 for ; Tue, 4 Nov 2003 15:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH7fY-0004Y3-00 for simple@ietf.org; Tue, 04 Nov 2003 15:20:52 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AH7fY-0004XR-00 for simple@ietf.org; Tue, 04 Nov 2003 15:20:52 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2003 12:20:41 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA4KKGAx009917; Tue, 4 Nov 2003 12:20:19 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADS32063; Tue, 4 Nov 2003 15:20:15 -0500 (EST) Message-ID: <3FA809FF.5010102@cisco.com> 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: Jonathan Rosenberg CC: mikko.lonnfors@nokia.com, simple@ietf.org Subject: Re: [Simple] Re: draft-lonnfors-simple-prescaps-ext-02 References: <0C1353ABB1DEB74DB067ADFF749C4EEF01C1DBD2@esebe004.ntc.nokia.com> <3FA67069.90405@cisco.com> <3FA718A0.80408@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 15:20:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >>> There are currently two ways that String types are used: >>> - enumerated types (like class) >>> - lists (like methods) >>> For enumeration types negation is easily added into XML syntax. For >>> lists this is not that trivial. One option is to add negation as ! mark >>> into value string like: INVITE, !MESSAGE. Other >>> alternative would be to redesign these lists bit differently like: >>> >>> >>> INVITE >>> MESSAGE> >>> >>> Second alternative is bit heavier one but I still think it is the better >>> one. >> >> The first seems more convenient, to read, to generate, and to process. > > I prefer the second, actually. Generally, the reason is that it avoids > another layer of parsers to be implemented. The callee caps syntax is > not a pride point in design; its ugliness needed because of the > constraints of encoding the information as header parameters. XML gives > you a rich structure. Why bother defining a new syntax for lists within > an element, when you can use XML natively to do that? Similarly, I would > do negation with an attribute, rather than include the ! within the > value. I don't feel strongly about this. I agree that the callee caps syntax is nothing to be proud of. But if we don't like that syntax, maybe we should consider simply rerendering the 2533 syntax in xml. Perhaps something like: The description If we aren't going to do that, then we have to make a decision: do we do a syntax rich enough to map to all of 2533, or just to map all of what callee-caps can say, or somewhere in between. (I find it hard to pick someplace in between.) > Also, I don't see the need for a methods tag AND a method tag. > Why not: > > INVITE > MESSAGE Note that this approach does start to become wordy: INVITE OPTIONS BYE UPDATE PRACK SUBSCRIBE NOTIFY PUBLISH rather than: INVITE,OPTIONS,BYE,UPDATE,PRACK,SUBSCRIBE,NOTIFY,PUBLISH It also introduces a semantic issue: SUBSCRIBE NOTIFY means something quite different semantically in terms of matching algorithms than does: SUBSCRIBE presence even though syntactically they are very similar. One should result in a disjunction and the other in a conjunction. This can be dealt with via explanation text - that things corresponding to the same feature tag should first be combined into a disjunction, and then the results combined into a conjunction. But it would be clearer if the syntax was closer to the semantics. >> Well, presence publication is analogous to callee-caps. It >> standardizes nothing analogous to callerprefs - no matching algorithm. >> >> Nevertheless, the matching algorithms of callerprefs depend on the >> syntax of the values to determine case sensitive vs case insensitive >> matching. The specification of individual features specifies what >> kinds of values should be used, but the algorithms that process these >> aren't expected to know those definitions. >> >> So it is important to preserve the semantic of whether a particular >> value is to be compared in a case sensitive or case insensitive way. >> >> So I think I agree with your 2nd alternative in (2) above - we need >> something in the xml structure to indicate this. Because tokens are >> more frequently used than strings, it probably makes sense for the >> default to be tokens. > > I would rather propose that you have this as part of the xml element > itself, and so instead of using "other-tag", instead have "token", > "string", "range" etc. as elements: > > INVITE > Foobar > ball Hadn't thought of that. I sort of like the approach. >> Maybe could do something like: >> >> >> INVITE,OPTIONS,BYE >> >> <=3,=5 >> >> A string, with comma >> > > I would prefer: > > > Are you competing to be champion of verbosity? :-) There is also negation to deal with here. Could do: or Namely, just expand the list of relational operations to be complete: eq, ne, gt, ge, lt, le so that negation isn't needed. That also can be used to cover true ranges too. E.g. priority="#3:5" could be: It isn't needed for booleans or strings either, so then we only need to support negation for tokens. As it happens, the way negation is defined in callee-caps, negation with tokens only makes sense in one very limited case - a single negated token. Any other case is degenerate: - methods="!PRACK,!UPDATE" matches PRACK, UPDATE, and everything else - methods="!PRACK,INVITE" is same as methods="!PRACK" Having talked thru all this, I think I am inclined to seek something semantically equivalent to the 2533 syntax, while perhaps being more concise than a literal transformation. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 17:18:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08649; Tue, 4 Nov 2003 17:18:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9V8-0006mI-00; Tue, 04 Nov 2003 17:18:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9V8-0006mD-00; Tue, 04 Nov 2003 17:18:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Uv-0001tC-He; Tue, 04 Nov 2003 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9UH-0001ju-GN for simple@optimus.ietf.org; Tue, 04 Nov 2003 17:17:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08569; Tue, 4 Nov 2003 17:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9UF-0006l7-00; Tue, 04 Nov 2003 17:17:19 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AH9UE-0006kY-00; Tue, 04 Nov 2003 17:17:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hA4MGZd08190; Tue, 4 Nov 2003 16:16:35 -0600 From: Robert Sparks To: agenda@ietf.org Cc: simple@ietf.org Content-Type: text/plain Message-Id: <1067984183.939.77.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] AGENDA: SIMPLE IETF58 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 16:16:23 -0600 Content-Transfer-Encoding: 7bit SIMPLE Agenda IETF 58 Thursday 11/13/03 - Morning Sesson 0900-1130 Salon A 0h 10m : Agenda bashing, status (chairs) 1h 00m : msrp (Ben) draft-ietf-simple-message-sessions-02.txt 0h 35m : pdoc-usage (Robert) draft-sparks-simple-pdoc-usage-00.txt 0h 45m : xcap (Jonathan) draft-ietf-simple-xcap-01.txt draft-ietf-simple-xcap-auth-usage-01.txt draft-ietf-simple-xcap-list-usage-01.txt Thursday 11/13/03 - Afternoon I 1300-1500 Salon A 0h 15m : filtering (Hisham) draft-khartabil-simple-filter-format-01.txt 0h 15m : partial-notification (Mikko) draft-ietf-simple-partial-notify-00.txt 0h 15m : prescaps (Mikko) draft-lonnfors-simple-prescaps-ext-02.txt 0h 15m : presence/im-wireless-reqs (Aki/Krisztian) draft-niemi-simple-im-wireless-reqs-02.txt draft-kiss-simple-presence-wireless-reqs-03.txt 0h 15m : winfo-history (Aki) draft-niemi-simple-winfo-history-00.txt 0h 15m : adhoc-event-list (Orit) draft-levin-simple-adhoc-list-00.txt 0h 15m : xcap-publish-usage (Markus) draft-isomaki-simple-xcap-publish-usage-00.txt 0h 15m : summary, review of assigned actions (chairs) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 17:18:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08671 for ; Tue, 4 Nov 2003 17:18:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9VB-0001vK-PB for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 17:18:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MIH0e007388 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 17:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9VB-0001v5-LN for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:18:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08649; Tue, 4 Nov 2003 17:18:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9V8-0006mI-00; Tue, 04 Nov 2003 17:18:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9V8-0006mD-00; Tue, 04 Nov 2003 17:18:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Uv-0001tC-He; Tue, 04 Nov 2003 17:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9UH-0001ju-GN for simple@optimus.ietf.org; Tue, 04 Nov 2003 17:17:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08569; Tue, 4 Nov 2003 17:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9UF-0006l7-00; Tue, 04 Nov 2003 17:17:19 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AH9UE-0006kY-00; Tue, 04 Nov 2003 17:17:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hA4MGZd08190; Tue, 4 Nov 2003 16:16:35 -0600 From: Robert Sparks To: agenda@ietf.org Cc: simple@ietf.org Content-Type: text/plain Message-Id: <1067984183.939.77.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] AGENDA: SIMPLE IETF58 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 16:16:23 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIMPLE Agenda IETF 58 Thursday 11/13/03 - Morning Sesson 0900-1130 Salon A 0h 10m : Agenda bashing, status (chairs) 1h 00m : msrp (Ben) draft-ietf-simple-message-sessions-02.txt 0h 35m : pdoc-usage (Robert) draft-sparks-simple-pdoc-usage-00.txt 0h 45m : xcap (Jonathan) draft-ietf-simple-xcap-01.txt draft-ietf-simple-xcap-auth-usage-01.txt draft-ietf-simple-xcap-list-usage-01.txt Thursday 11/13/03 - Afternoon I 1300-1500 Salon A 0h 15m : filtering (Hisham) draft-khartabil-simple-filter-format-01.txt 0h 15m : partial-notification (Mikko) draft-ietf-simple-partial-notify-00.txt 0h 15m : prescaps (Mikko) draft-lonnfors-simple-prescaps-ext-02.txt 0h 15m : presence/im-wireless-reqs (Aki/Krisztian) draft-niemi-simple-im-wireless-reqs-02.txt draft-kiss-simple-presence-wireless-reqs-03.txt 0h 15m : winfo-history (Aki) draft-niemi-simple-winfo-history-00.txt 0h 15m : adhoc-event-list (Orit) draft-levin-simple-adhoc-list-00.txt 0h 15m : xcap-publish-usage (Markus) draft-isomaki-simple-xcap-publish-usage-00.txt 0h 15m : summary, review of assigned actions (chairs) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 17:21:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08797; Tue, 4 Nov 2003 17:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Yr-0006pr-00; Tue, 04 Nov 2003 17:22:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9Yr-0006po-00; Tue, 04 Nov 2003 17:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yo-0002V0-P5; Tue, 04 Nov 2003 17:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwHR-0006Is-S7 for simple@optimus.ietf.org; Tue, 04 Nov 2003 03:11:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03097 for ; Tue, 4 Nov 2003 03:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwHN-0000TP-00 for simple@ietf.org; Tue, 04 Nov 2003 03:11:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AGwHN-0000TM-00 for simple@ietf.org; Tue, 04 Nov 2003 03:11:09 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA48B7Y21358 for ; Tue, 4 Nov 2003 10:11:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 10:11:06 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 10:11:05 +0200 Received: from nokia.com (xitami.research.nokia.com [172.21.40.110]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id KAA20216 for ; Tue, 4 Nov 2003 10:11:07 +0200 (EET) X-Authentication-Warning: mgw.research.nokia.com: Host xitami.research.nokia.com [172.21.40.110] claimed to be nokia.com Message-ID: <3FA75F19.8080802@nokia.com> From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 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: 04 Nov 2003 08:11:05.0803 (UTC) FILETIME=[31F939B0:01C3A2AB] Content-Transfer-Encoding: 7bit Subject: [Simple] Managing XCAP Etags Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 10:11:05 +0200 Content-Transfer-Encoding: 7bit Hi all, As entity tags should be updated according to current XCAP-draft by element/node/attribute basis, synchronization between the client and server is fairly complicated. While I understand that the aim is to allow fine-grained partial updates to the xml-documents, but after many partial updates one document may have a lot of "tree-like" ETag metadata. The problem is how to get this metadata to the client ? If you havn't followed the history of the document, i.e you are fetching some new document with http get and you'll receive e.g. only the root Etag then. What about the other Etags within xml-tree ? Certainly, you could get them by XPATH-queries according to the document, but that is way too ugly. Instead, I'll propose that only document based Etag is used, as it allows a simple integrity test for partial updates and is also much simpler to implement. BR, Jari Urpalainen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 17:22:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08882 for ; Tue, 4 Nov 2003 17:22:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yv-0002iL-CQ for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 17:22:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4MM9g0010414 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 17:22:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yu-0002hr-Fa for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 17:22:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08797; Tue, 4 Nov 2003 17:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH9Yr-0006pr-00; Tue, 04 Nov 2003 17:22:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AH9Yr-0006po-00; Tue, 04 Nov 2003 17:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH9Yo-0002V0-P5; Tue, 04 Nov 2003 17:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGwHR-0006Is-S7 for simple@optimus.ietf.org; Tue, 04 Nov 2003 03:11:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03097 for ; Tue, 4 Nov 2003 03:11:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGwHN-0000TP-00 for simple@ietf.org; Tue, 04 Nov 2003 03:11:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AGwHN-0000TM-00 for simple@ietf.org; Tue, 04 Nov 2003 03:11:09 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA48B7Y21358 for ; Tue, 4 Nov 2003 10:11:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Nov 2003 10:11:06 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 4 Nov 2003 10:11:05 +0200 Received: from nokia.com (xitami.research.nokia.com [172.21.40.110]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id KAA20216 for ; Tue, 4 Nov 2003 10:11:07 +0200 (EET) X-Authentication-Warning: mgw.research.nokia.com: Host xitami.research.nokia.com [172.21.40.110] claimed to be nokia.com Message-ID: <3FA75F19.8080802@nokia.com> From: Jari Urpalainen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 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: 04 Nov 2003 08:11:05.0803 (UTC) FILETIME=[31F939B0:01C3A2AB] Content-Transfer-Encoding: 7bit Subject: [Simple] Managing XCAP Etags Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 10:11:05 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, As entity tags should be updated according to current XCAP-draft by element/node/attribute basis, synchronization between the client and server is fairly complicated. While I understand that the aim is to allow fine-grained partial updates to the xml-documents, but after many partial updates one document may have a lot of "tree-like" ETag metadata. The problem is how to get this metadata to the client ? If you havn't followed the history of the document, i.e you are fetching some new document with http get and you'll receive e.g. only the root Etag then. What about the other Etags within xml-tree ? Certainly, you could get them by XPATH-queries according to the document, but that is way too ugly. Instead, I'll propose that only document based Etag is used, as it allows a simple integrity test for partial updates and is also much simpler to implement. BR, Jari Urpalainen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 4 20:28:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15087; Tue, 4 Nov 2003 20:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCTs-0001ET-00; Tue, 04 Nov 2003 20:29:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHCTr-0001EQ-00; Tue, 04 Nov 2003 20:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCTl-0005yC-Pa; Tue, 04 Nov 2003 20:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCTE-0005xM-2T for simple@optimus.ietf.org; Tue, 04 Nov 2003 20:28:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15066; Tue, 4 Nov 2003 20:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCTB-0001Dw-00; Tue, 04 Nov 2003 20:28:25 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AHCTB-0001DM-00; Tue, 04 Nov 2003 20:28:25 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA51RlYe006227; Tue, 4 Nov 2003 20:27:47 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA51RXf11536; Tue, 4 Nov 2003 20:27:33 -0500 Message-ID: <3FA85205.6060303@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> <3FA34FAD.2020500@cs.columbia.edu> <3FA6FB5B.2000209@dynamicsoft.com> In-Reply-To: <3FA6FB5B.2000209@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 20:27:33 -0500 Content-Transfer-Encoding: 7bit > > My main point, however, is that none of my arguments above are specific > to presence as opposed to geopriv. If blacklists are bad for geopriv, > they are also bad for presence, and vice a versa. Most certainly - the arguments for and against are unrelated to the domain. I still think that blacklists are a bad idea. Even in a company situation, it is quite common for users to have multiple identifiers. I can be reached under at least three identifiers, and can indeed create any number of new ones at any time. (Like for any sendmail-based system, hgs+anything@cs will work. That's how I know which spammer is harvesting Internet drafts for email addresses :-)) This is probably a good feature, since cheap identifiers, created for specific purposes, are one advantage that IP-based systems have compared to, say, the phone system. I prefer conceptually consistent models, i.e., with a very simple set of rules with no exceptions. The additive-permissions model, I believe, offers that, so in my book, the burden of proof is particularly high if the base model is violated. > I am with you on removing features, and as you can see have taken the > axe to xcap-auth in a pretty serious way. I am also totally in agreement > with the value of something being privacy-safe. I think the concerns > about except-clauses in the applies-to section only apply when the > except-clauses reference external lists. I see several options there: > > (1) don't allow except clauses to reference external lists at all The problem is if the external element has an except clause, not the referencing document. Note that it is quite possible that the same applies-to appears in multiple rules. > > (2) allow them to reference lists present only on the same server Even that is insufficient. Different documents can have different permissions or be on different file systems. It is, in general, rather difficult to ensure that two files will always be accessible simultaneously and atomically, regardless of whether they are on the same server or not. > > (3) AND/OR if the list cannot be obtained, then the permissions in the > associated statement are granted to NO ONE. Yet one more exception to worry about. There are other composing operations that may take place, e.g., company policy and personal policy. As soon as you violate the additive property anywhere, we have to worry about this everywhere, with serious consequences if we or the implementor get it wrong. > > > I believe that (1), (2,3) or (3) would make the except clause privacy safe. I'm still unconvinced that blacklists are sufficiently easy to explain to users (with all their practical limitations) that they are worth breaking the basic additive-rule principle with a set of complicated exceptions. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 4 20:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15126 for ; Tue, 4 Nov 2003 20:29:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCTw-00060l-9o for simple-archive@odin.ietf.org; Tue, 04 Nov 2003 20:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA51TBdl023101 for simple-archive@odin.ietf.org; Tue, 4 Nov 2003 20:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCTv-00060V-0X for simple-web-archive@optimus.ietf.org; Tue, 04 Nov 2003 20:29:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15087; Tue, 4 Nov 2003 20:28:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCTs-0001ET-00; Tue, 04 Nov 2003 20:29:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHCTr-0001EQ-00; Tue, 04 Nov 2003 20:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCTl-0005yC-Pa; Tue, 04 Nov 2003 20:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHCTE-0005xM-2T for simple@optimus.ietf.org; Tue, 04 Nov 2003 20:28:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15066; Tue, 4 Nov 2003 20:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHCTB-0001Dw-00; Tue, 04 Nov 2003 20:28:25 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AHCTB-0001DM-00; Tue, 04 Nov 2003 20:28:25 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA51RlYe006227; Tue, 4 Nov 2003 20:27:47 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA51RXf11536; Tue, 4 Nov 2003 20:27:33 -0500 Message-ID: <3FA85205.6060303@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03C1@mchp905a.mch.sbs.de> <3FA34FAD.2020500@cs.columbia.edu> <3FA6FB5B.2000209@dynamicsoft.com> In-Reply-To: <3FA6FB5B.2000209@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 04 Nov 2003 20:27:33 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > My main point, however, is that none of my arguments above are specific > to presence as opposed to geopriv. If blacklists are bad for geopriv, > they are also bad for presence, and vice a versa. Most certainly - the arguments for and against are unrelated to the domain. I still think that blacklists are a bad idea. Even in a company situation, it is quite common for users to have multiple identifiers. I can be reached under at least three identifiers, and can indeed create any number of new ones at any time. (Like for any sendmail-based system, hgs+anything@cs will work. That's how I know which spammer is harvesting Internet drafts for email addresses :-)) This is probably a good feature, since cheap identifiers, created for specific purposes, are one advantage that IP-based systems have compared to, say, the phone system. I prefer conceptually consistent models, i.e., with a very simple set of rules with no exceptions. The additive-permissions model, I believe, offers that, so in my book, the burden of proof is particularly high if the base model is violated. > I am with you on removing features, and as you can see have taken the > axe to xcap-auth in a pretty serious way. I am also totally in agreement > with the value of something being privacy-safe. I think the concerns > about except-clauses in the applies-to section only apply when the > except-clauses reference external lists. I see several options there: > > (1) don't allow except clauses to reference external lists at all The problem is if the external element has an except clause, not the referencing document. Note that it is quite possible that the same applies-to appears in multiple rules. > > (2) allow them to reference lists present only on the same server Even that is insufficient. Different documents can have different permissions or be on different file systems. It is, in general, rather difficult to ensure that two files will always be accessible simultaneously and atomically, regardless of whether they are on the same server or not. > > (3) AND/OR if the list cannot be obtained, then the permissions in the > associated statement are granted to NO ONE. Yet one more exception to worry about. There are other composing operations that may take place, e.g., company policy and personal policy. As soon as you violate the additive property anywhere, we have to worry about this everywhere, with serious consequences if we or the implementor get it wrong. > > > I believe that (1), (2,3) or (3) would make the except clause privacy safe. I'm still unconvinced that blacklists are sufficiently easy to explain to users (with all their practical limitations) that they are worth breaking the basic additive-rule principle with a set of complicated exceptions. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 07:18:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02597; Wed, 5 Nov 2003 07:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMc4-0002YG-00; Wed, 05 Nov 2003 07:18:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHMc4-0002YD-00; Wed, 05 Nov 2003 07:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMbp-0004m5-Oo; Wed, 05 Nov 2003 07:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMbl-0004lQ-5A for simple@optimus.ietf.org; Wed, 05 Nov 2003 07:17:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02547 for ; Wed, 5 Nov 2003 07:17:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMbk-0002Wr-00 for simple@ietf.org; Wed, 05 Nov 2003 07:17:56 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHMbj-0002Wn-00 for simple@ietf.org; Wed, 05 Nov 2003 07:17:56 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5CHsY09277 for ; Wed, 5 Nov 2003 14:17:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Nov 2003 14:17:53 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 14:17:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Event Notification Filtering Drafts Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797385@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Event Notification Filtering Drafts Thread-Index: AcOiizlr2EVh8LRORn+AEvJvKxXtBABA0N6g To: Cc: X-OriginalArrivalTime: 05 Nov 2003 12:17:54.0071 (UTC) FILETIME=[D6CD5A70:01C3A396] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 14:17:47 +0200 Content-Transfer-Encoding: quoted-printable Jonathan, Thank you for the interest in this work. Come comments inline... > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 04, 2003 4:55 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Event Notification Filtering Drafts >=20 >=20 > Hisham, >=20 > Thanks for your continued work on this. >=20 > A few comments. Firstly, the filter format seems quite=20 > complicated. It=20 > is very rich, allowing for conditional inclusions, inclusion by=20 > namespace and element names, triggers of various kinds,=20 > inclusions and=20 > exclusions, and level filtering. As we did with xcap-auth, I=20 > wonder if=20 > we should scale this back a bit, and start small. Instead, focus on=20 > the real must-haves that are needed today, and ensure that there is=20 > sufficient extensibility to add some of the other stuff later. Of course we can scale down. Lets me list the features and describe = their importance: - conditional inclusions: only include tuples with certain values (eg: = basic value of open or class value of MMS). I think this is needed. The = syntax can of course be simplified as follows: - remove the element - elements carry the condition in a xpath like expression: = //tuple[class=3D"MMS"]/status - level: if we require the subscriber to explicitly list (using = s) all the elements and attributes that it wants, then we can = do without the levelling: descendent, ancestor, and self. - inclusion by namespace: It could be that a subscriber does not = understand all namespaces and so would like to filter out other = namespaces. It does that by specifying the namespace it wants included. - exclusion: If a subscriber explicitly specifies the includes, it no = longer needs to specify the excludes. The only scenario that remains = with exclude is when a subscribe includes a namespace and then wants to = exclude elements from that namespace. I don't think this is so = complicated and can remain. - type: we need the namespace and xml-element types. We can do without = the token. - triggering: there are 3 ways to trigger a notification: = Element/attribute value has changed, an element/attribute was added, and = an element/attribute was removed. - changed: this is the essence of trigger filtering and is needed, = IMO. - Added and removed: an example of this is that a notifier did not = include a element in the original NOTIFY, and I want to know = when the element is added. I'm on the border = with these 2. >=20 > Secondly, you have defined your own xpath-type syntax. Interestingly,=20 > I did a similar thing in the xcap spec. Your syntax covers a superset=20 > of the functionality I am providing. Can we get away with just one=20 > format?=20 Sure we can. They are very close as they are now. Your syntax does not = allow things like // and * and you need to explicitly express the full = path of an element. I'm not sure if // or * are allowed in an http URI. = I think those 2 are needed for , especially if you don't care = about the position that an element appears in . > Indeed, depending on the scope there may not be a need for=20 > xpath style expressions at all. I booted them out of xcap-auth, in=20 > fact. i've backed down from the position that they don't make=20 > sense in=20 > a filter; I think they do. However, there is still a question if=20 > they are needed at all. I think they are needed or the reasons above. We also can't mandate that = any extension to pidf will not include 2 elements with the same name. = eg: >=20 > It seems that the filter format could cause the presence server to=20 > create presence documents that are not schema compliant. That shoudnt=20 > be allowed. Unfortunately, its not clear that this could be known at=20 > the time the filter is uploaded. How do we deal with error=20 > handling in=20 > this case? One option is to reduce the scope to make sure that the=20 > filters cannot cause the server to create presence documents that=20 > arent schema compliant. We have text in the format draft as well as the functionality draft how = to handle this. There are 2 ways: reject the request (if this is know = when filter is uploaded) or the server includes all mandatory = elements/attributes required to make the resulting XML document a valid = one.=20 >=20 > There could be some potential for confusion around namespaces. You=20 > need to allow for addressing of elements using fully qualified names=20 > (i.e., prefix:local-name). In this case, is the prefix the=20 > one defined=20 > in the filter document, or in the presence document? FOr example: >=20 > filter: >=20 > > xmlns:foo=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple" > package=3D"presence"> > > > type=3D"xml-element">foo:class=3D"IM" or rpid:class=3D"SMS" or=20 > rpid:class=3D"MMS" > > type=3D"xml-element">//tuple > //tuple > //tuple > > > >=20 >=20 >=20 > and presence document: >=20 > > > SMS > open > > >=20 >=20 > I believe that the prefix is purely local to the XML document=20 > in which=20 > its defined, in whcih case the filter would remove the class element=20 > in the presence document above. But, you probably want to clearly=20 > define the matching operations to make sure this is so. The=20 > namespaces=20 > specification has some text on canonicalization which can=20 > probably help. Actually, in this example, the tuple is not selected as all. In any = case, I think you are right. We need to explain this namespace issue a = little more. Regards, Hisham >=20 >=20 >=20 > Thanks, > Jonathan R. > hisham.khartabil@nokia.com wrote: >=20 > > An update to the Event Notification Filtering solutions is=20 > now available. > >=20 > > The XML format is defined in: > >=20 > http://www.ietf.org/internet-drafts/draft-khartabil-simple-fil ter-format-01.txt >=20 > The functionality draft is defined in: > = http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-0= 1.txt >=20 > One major change in the format draft is that we removed the xpath = expression and defined a trimmed down version suitable for the filtering = solution needs. The functionality draft changes were minor. >=20 > The requirements drafts can be found behind the following links: > = http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02= .txt > = http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-0= 0.txt >=20 > There has been no update to the requirements document due to lack of = comments. >=20 > Regards, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 07:18:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02613 for ; Wed, 5 Nov 2003 07:18:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMc6-0004qt-1Z for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 07:18:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5CIIFK018647 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 07:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMc5-0004qg-TB for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 07:18:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02597; Wed, 5 Nov 2003 07:18:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMc4-0002YG-00; Wed, 05 Nov 2003 07:18:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHMc4-0002YD-00; Wed, 05 Nov 2003 07:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMbp-0004m5-Oo; Wed, 05 Nov 2003 07:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHMbl-0004lQ-5A for simple@optimus.ietf.org; Wed, 05 Nov 2003 07:17:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02547 for ; Wed, 5 Nov 2003 07:17:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHMbk-0002Wr-00 for simple@ietf.org; Wed, 05 Nov 2003 07:17:56 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHMbj-0002Wn-00 for simple@ietf.org; Wed, 05 Nov 2003 07:17:56 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5CHsY09277 for ; Wed, 5 Nov 2003 14:17:54 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Nov 2003 14:17:53 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 14:17:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Event Notification Filtering Drafts Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797385@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Event Notification Filtering Drafts Thread-Index: AcOiizlr2EVh8LRORn+AEvJvKxXtBABA0N6g To: Cc: X-OriginalArrivalTime: 05 Nov 2003 12:17:54.0071 (UTC) FILETIME=[D6CD5A70:01C3A396] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 14:17:47 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Jonathan, Thank you for the interest in this work. Come comments inline... > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 04, 2003 4:55 AM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Event Notification Filtering Drafts >=20 >=20 > Hisham, >=20 > Thanks for your continued work on this. >=20 > A few comments. Firstly, the filter format seems quite=20 > complicated. It=20 > is very rich, allowing for conditional inclusions, inclusion by=20 > namespace and element names, triggers of various kinds,=20 > inclusions and=20 > exclusions, and level filtering. As we did with xcap-auth, I=20 > wonder if=20 > we should scale this back a bit, and start small. Instead, focus on=20 > the real must-haves that are needed today, and ensure that there is=20 > sufficient extensibility to add some of the other stuff later. Of course we can scale down. Lets me list the features and describe = their importance: - conditional inclusions: only include tuples with certain values (eg: = basic value of open or class value of MMS). I think this is needed. The = syntax can of course be simplified as follows: - remove the element - elements carry the condition in a xpath like expression: = //tuple[class=3D"MMS"]/status - level: if we require the subscriber to explicitly list (using = s) all the elements and attributes that it wants, then we can = do without the levelling: descendent, ancestor, and self. - inclusion by namespace: It could be that a subscriber does not = understand all namespaces and so would like to filter out other = namespaces. It does that by specifying the namespace it wants included. - exclusion: If a subscriber explicitly specifies the includes, it no = longer needs to specify the excludes. The only scenario that remains = with exclude is when a subscribe includes a namespace and then wants to = exclude elements from that namespace. I don't think this is so = complicated and can remain. - type: we need the namespace and xml-element types. We can do without = the token. - triggering: there are 3 ways to trigger a notification: = Element/attribute value has changed, an element/attribute was added, and = an element/attribute was removed. - changed: this is the essence of trigger filtering and is needed, = IMO. - Added and removed: an example of this is that a notifier did not = include a element in the original NOTIFY, and I want to know = when the element is added. I'm on the border = with these 2. >=20 > Secondly, you have defined your own xpath-type syntax. Interestingly,=20 > I did a similar thing in the xcap spec. Your syntax covers a superset=20 > of the functionality I am providing. Can we get away with just one=20 > format?=20 Sure we can. They are very close as they are now. Your syntax does not = allow things like // and * and you need to explicitly express the full = path of an element. I'm not sure if // or * are allowed in an http URI. = I think those 2 are needed for , especially if you don't care = about the position that an element appears in . > Indeed, depending on the scope there may not be a need for=20 > xpath style expressions at all. I booted them out of xcap-auth, in=20 > fact. i've backed down from the position that they don't make=20 > sense in=20 > a filter; I think they do. However, there is still a question if=20 > they are needed at all. I think they are needed or the reasons above. We also can't mandate that = any extension to pidf will not include 2 elements with the same name. = eg: >=20 > It seems that the filter format could cause the presence server to=20 > create presence documents that are not schema compliant. That shoudnt=20 > be allowed. Unfortunately, its not clear that this could be known at=20 > the time the filter is uploaded. How do we deal with error=20 > handling in=20 > this case? One option is to reduce the scope to make sure that the=20 > filters cannot cause the server to create presence documents that=20 > arent schema compliant. We have text in the format draft as well as the functionality draft how = to handle this. There are 2 ways: reject the request (if this is know = when filter is uploaded) or the server includes all mandatory = elements/attributes required to make the resulting XML document a valid = one.=20 >=20 > There could be some potential for confusion around namespaces. You=20 > need to allow for addressing of elements using fully qualified names=20 > (i.e., prefix:local-name). In this case, is the prefix the=20 > one defined=20 > in the filter document, or in the presence document? FOr example: >=20 > filter: >=20 > > xmlns:foo=3D"urn:ietf:params:xml:ns:pidf:rpid-tuple" > package=3D"presence"> > > > type=3D"xml-element">foo:class=3D"IM" or rpid:class=3D"SMS" or=20 > rpid:class=3D"MMS" > > type=3D"xml-element">//tuple > //tuple > //tuple > > > >=20 >=20 >=20 > and presence document: >=20 > > > SMS > open > > >=20 >=20 > I believe that the prefix is purely local to the XML document=20 > in which=20 > its defined, in whcih case the filter would remove the class element=20 > in the presence document above. But, you probably want to clearly=20 > define the matching operations to make sure this is so. The=20 > namespaces=20 > specification has some text on canonicalization which can=20 > probably help. Actually, in this example, the tuple is not selected as all. In any = case, I think you are right. We need to explain this namespace issue a = little more. Regards, Hisham >=20 >=20 >=20 > Thanks, > Jonathan R. > hisham.khartabil@nokia.com wrote: >=20 > > An update to the Event Notification Filtering solutions is=20 > now available. > >=20 > > The XML format is defined in: > >=20 > http://www.ietf.org/internet-drafts/draft-khartabil-simple-fil ter-format-01.txt >=20 > The functionality draft is defined in: > = http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-0= 1.txt >=20 > One major change in the format draft is that we removed the xpath = expression and defined a trimmed down version suitable for the filtering = solution needs. The functionality draft changes were minor. >=20 > The requirements drafts can be found behind the following links: > = http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02= .txt > = http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-0= 0.txt >=20 > There has been no update to the requirements document due to lack of = comments. >=20 > Regards, > Hisham >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 09:10:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06087; Wed, 5 Nov 2003 09:10:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHONI-0004hb-00; Wed, 05 Nov 2003 09:11:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHONI-0004hW-00; Wed, 05 Nov 2003 09:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHONB-0003R8-JO; Wed, 05 Nov 2003 09:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOMj-0003QY-4Y for simple@optimus.ietf.org; Wed, 05 Nov 2003 09:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06075 for ; Wed, 5 Nov 2003 09:10:20 -0500 (EST) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOMh-0004hQ-00 for simple@ietf.org; Wed, 05 Nov 2003 09:10:31 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHOMg-0004hN-00 for simple@ietf.org; Wed, 05 Nov 2003 09:10:31 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5EAQF28874 for ; Wed, 5 Nov 2003 16:10:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Nov 2003 16:10:25 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 16:10:25 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 16:10:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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-xcap-01.txt -> comments Message-ID: <902B96A872B24840B48412649C0E8A42012FD7D3@trebe003.europe.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-01.txt Thread-Index: AcOeTPKi6RmZzKXUQtSDw9aJNA6ZygFVzxpg To: , X-OriginalArrivalTime: 05 Nov 2003 14:10:25.0537 (UTC) FILETIME=[8EFD4F10:01C3A3A6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 16:10:24 +0200 Content-Transfer-Encoding: quoted-printable Hi, Thanks for the new version of the XCAP draft! It was nice to see that it = was still improved, and more "exact" than the previous version. I have only a couple of = comments for the draft. I think that there could be more exact definition on what is exactly the = "real" content to be handled by the following three operations: - 6.5. "Creating a new element" This chapter says that "The content in the request MUST be an XML = element." However, shouldn't it state that=20 "the content is an XML element and associated content (including = children elements)" OR "the content is the portion of the XML document = starding with the left bracket of the begin tag of the element, ending = with the right bracket of the end tag of the element." as said in the = later chapters concerning the PUT and/or GET operations? - 6.6. "Replacing an element in the document The same comment as for the "creating a new element" applies also to = this chapter. - 6.7. "Delete an Element * The chapter says "...containing the elements to be deleted": is it = possible to delete elements from several parts of the document using one = "delete an element" operation or should the node selector point to only = one element? This could be clarified in the chapter. * the same comments as for the chapter 6.5 also applies here: shouldn't = the "delete" remove the element plus its sub-tree? BR, Eva Leppanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 09:11:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06121 for ; Wed, 5 Nov 2003 09:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHONK-0003S1-QW for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 09:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5EBAH4013259 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 09:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHONK-0003Rm-NE for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 09:11:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06087; Wed, 5 Nov 2003 09:10:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHONI-0004hb-00; Wed, 05 Nov 2003 09:11:08 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHONI-0004hW-00; Wed, 05 Nov 2003 09:11:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHONB-0003R8-JO; Wed, 05 Nov 2003 09:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOMj-0003QY-4Y for simple@optimus.ietf.org; Wed, 05 Nov 2003 09:10:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06075 for ; Wed, 5 Nov 2003 09:10:20 -0500 (EST) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOMh-0004hQ-00 for simple@ietf.org; Wed, 05 Nov 2003 09:10:31 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHOMg-0004hN-00 for simple@ietf.org; Wed, 05 Nov 2003 09:10:31 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5EAQF28874 for ; Wed, 5 Nov 2003 16:10:27 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Nov 2003 16:10:25 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 16:10:25 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 16:10:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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-xcap-01.txt -> comments Message-ID: <902B96A872B24840B48412649C0E8A42012FD7D3@trebe003.europe.nokia.com> Thread-Topic: [Simple] I-D ACTION:draft-ietf-simple-xcap-01.txt Thread-Index: AcOeTPKi6RmZzKXUQtSDw9aJNA6ZygFVzxpg To: , X-OriginalArrivalTime: 05 Nov 2003 14:10:25.0537 (UTC) FILETIME=[8EFD4F10:01C3A3A6] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 16:10:24 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Thanks for the new version of the XCAP draft! It was nice to see that it = was still improved, and more "exact" than the previous version. I have only a couple of = comments for the draft. I think that there could be more exact definition on what is exactly the = "real" content to be handled by the following three operations: - 6.5. "Creating a new element" This chapter says that "The content in the request MUST be an XML = element." However, shouldn't it state that=20 "the content is an XML element and associated content (including = children elements)" OR "the content is the portion of the XML document = starding with the left bracket of the begin tag of the element, ending = with the right bracket of the end tag of the element." as said in the = later chapters concerning the PUT and/or GET operations? - 6.6. "Replacing an element in the document The same comment as for the "creating a new element" applies also to = this chapter. - 6.7. "Delete an Element * The chapter says "...containing the elements to be deleted": is it = possible to delete elements from several parts of the document using one = "delete an element" operation or should the node selector point to only = one element? This could be clarified in the chapter. * the same comments as for the chapter 6.5 also applies here: shouldn't = the "delete" remove the element plus its sub-tree? BR, Eva Leppanen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 09:21:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06410; Wed, 5 Nov 2003 09:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOXy-0004q2-00; Wed, 05 Nov 2003 09:22:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHOXy-0004pz-00; Wed, 05 Nov 2003 09:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOXq-0003ud-2E; Wed, 05 Nov 2003 09:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOXm-0003tn-Ct for simple@optimus.ietf.org; Wed, 05 Nov 2003 09:21:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06395 for ; Wed, 5 Nov 2003 09:21:44 -0500 (EST) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOXk-0004pa-00 for simple@ietf.org; Wed, 05 Nov 2003 09:21:56 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHOXi-0004pX-00 for simple@ietf.org; Wed, 05 Nov 2003 09:21:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5EKHF12783 for ; Wed, 5 Nov 2003 16:21:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Nov 2003 16:19:40 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Nov 2003 16:19:39 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 16:19:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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-xcap-auth-usage-01.txt -> comments Message-ID: <902B96A872B24840B48412649C0E8A42012FD7D4@trebe003.europe.nokia.com> Thread-Topic: RE: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-01.txt -> comments Thread-Index: AcOjp9jQPzMldOALQ16YNJxTTOFHJg== To: , X-OriginalArrivalTime: 05 Nov 2003 14:19:39.0861 (UTC) FILETIME=[D9647050:01C3A3A7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 16:19:39 +0200 Content-Transfer-Encoding: quoted-printable Hi, Thanks for the new version! Please find below a couple of comments. - The draft mentions still in a couple of places the "when" (~rule = permissions) issue even if it has been removed from the=20 current version. The chapters are:=20 * the first sub-chapter of the "1. introduction" ("...but also includes = decisions about when the watcher should receive notifications...") and=20 * the first sub-chapter of the chapter 2 ("...a condition under which a = notification is sent or is not sent...") - 4.2.2.2. Content permissions * The "show-element" does not clearly indicate whether e.g. the = sub-tree of the indicated element will be delivered or not. - 4.4. Naming Conventions * Just for clarification: is it possible to use the definitions of the = "global" sub-tree or is the presence authorisation limited to the = "users" sub-tree? - 4.6. XML Schema * the schema is missing - 5. Supported permissions * The "compound permissions" is mentioned in the introduction and the = example (5.6) but shouldn't they be removed? * Is the purpose of the example (5.6) to show an example of primitive = types or "combound permissions" (see the description of the example)? * the in the example document (5.6) has the value = "example": is the purpose to list all the supported elements or just to = indicate that the content permission is supported by the = server? BR, Eva _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 09:22:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06471 for ; Wed, 5 Nov 2003 09:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOY0-0003zW-K4 for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 09:22:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5EMCrn015342 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 09:22:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOY0-0003zN-H9 for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 09:22:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06410; Wed, 5 Nov 2003 09:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOXy-0004q2-00; Wed, 05 Nov 2003 09:22:10 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHOXy-0004pz-00; Wed, 05 Nov 2003 09:22:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOXq-0003ud-2E; Wed, 05 Nov 2003 09:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHOXm-0003tn-Ct for simple@optimus.ietf.org; Wed, 05 Nov 2003 09:21:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06395 for ; Wed, 5 Nov 2003 09:21:44 -0500 (EST) From: eva-maria.leppanen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHOXk-0004pa-00 for simple@ietf.org; Wed, 05 Nov 2003 09:21:56 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHOXi-0004pX-00 for simple@ietf.org; Wed, 05 Nov 2003 09:21:55 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5EKHF12783 for ; Wed, 5 Nov 2003 16:21:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Nov 2003 16:19:40 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 5 Nov 2003 16:19:39 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 16:19:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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-xcap-auth-usage-01.txt -> comments Message-ID: <902B96A872B24840B48412649C0E8A42012FD7D4@trebe003.europe.nokia.com> Thread-Topic: RE: [Simple] I-D ACTION:draft-ietf-simple-xcap-auth-usage-01.txt -> comments Thread-Index: AcOjp9jQPzMldOALQ16YNJxTTOFHJg== To: , X-OriginalArrivalTime: 05 Nov 2003 14:19:39.0861 (UTC) FILETIME=[D9647050:01C3A3A7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 16:19:39 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Thanks for the new version! Please find below a couple of comments. - The draft mentions still in a couple of places the "when" (~rule = permissions) issue even if it has been removed from the=20 current version. The chapters are:=20 * the first sub-chapter of the "1. introduction" ("...but also includes = decisions about when the watcher should receive notifications...") and=20 * the first sub-chapter of the chapter 2 ("...a condition under which a = notification is sent or is not sent...") - 4.2.2.2. Content permissions * The "show-element" does not clearly indicate whether e.g. the = sub-tree of the indicated element will be delivered or not. - 4.4. Naming Conventions * Just for clarification: is it possible to use the definitions of the = "global" sub-tree or is the presence authorisation limited to the = "users" sub-tree? - 4.6. XML Schema * the schema is missing - 5. Supported permissions * The "compound permissions" is mentioned in the introduction and the = example (5.6) but shouldn't they be removed? * Is the purpose of the example (5.6) to show an example of primitive = types or "combound permissions" (see the description of the example)? * the in the example document (5.6) has the value = "example": is the purpose to list all the supported elements or just to = indicate that the content permission is supported by the = server? BR, Eva _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 10:06:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08212; Wed, 5 Nov 2003 10:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPEc-0005Tz-00; Wed, 05 Nov 2003 10:06:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPEb-0005Tw-00; Wed, 05 Nov 2003 10:06:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPEQ-0006Pi-83; Wed, 05 Nov 2003 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPEF-0006PM-Gb for simple@optimus.ietf.org; Wed, 05 Nov 2003 10:05:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08161 for ; Wed, 5 Nov 2003 10:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPED-0005Tl-00 for simple@ietf.org; Wed, 05 Nov 2003 10:05:49 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AHPEC-0005TT-00 for simple@ietf.org; Wed, 05 Nov 2003 10:05:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27846; Wed, 5 Nov 2003 10:05:16 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28909; Wed, 5 Nov 2003 10:05:17 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 10:05:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6087@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: jdrosen@dynamicsoft.com Cc: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Nit in xcap-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 10:05:11 -0500 In the ABNF in 5.2, there are definitions repeated for by-pos and by-attr. Also, double checking that the intention on these parameters is that no whitespace is allowed anywhere. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 10:06:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08283 for ; Wed, 5 Nov 2003 10:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPEf-0006Tk-CU for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 10:06:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5F6HYZ024898 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 10:06:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPEf-0006TV-8J for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 10:06:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08212; Wed, 5 Nov 2003 10:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPEc-0005Tz-00; Wed, 05 Nov 2003 10:06:14 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPEb-0005Tw-00; Wed, 05 Nov 2003 10:06:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPEQ-0006Pi-83; Wed, 05 Nov 2003 10:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPEF-0006PM-Gb for simple@optimus.ietf.org; Wed, 05 Nov 2003 10:05:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08161 for ; Wed, 5 Nov 2003 10:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPED-0005Tl-00 for simple@ietf.org; Wed, 05 Nov 2003 10:05:49 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AHPEC-0005TT-00 for simple@ietf.org; Wed, 05 Nov 2003 10:05:48 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27846; Wed, 5 Nov 2003 10:05:16 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28909; Wed, 5 Nov 2003 10:05:17 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 10:05:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6087@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: jdrosen@dynamicsoft.com Cc: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Nit in xcap-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 10:05:11 -0500 In the ABNF in 5.2, there are definitions repeated for by-pos and by-attr. Also, double checking that the intention on these parameters is that no whitespace is allowed anywhere. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 10:47:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10765; Wed, 5 Nov 2003 10:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPt7-000627-00; Wed, 05 Nov 2003 10:48:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPt6-000624-00; Wed, 05 Nov 2003 10:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPt2-0000wP-Pk; Wed, 05 Nov 2003 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPsj-0000wE-9Q for simple@optimus.ietf.org; Wed, 05 Nov 2003 10:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10762 for ; Wed, 5 Nov 2003 10:47:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPsg-000620-00 for simple@ietf.org; Wed, 05 Nov 2003 10:47:38 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHPsg-00061s-00 for simple@ietf.org; Wed, 05 Nov 2003 10:47:38 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5FlaY12527 for ; Wed, 5 Nov 2003 17:47:36 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Nov 2003 17:47:36 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 17:47:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Thread-Topic: Comments on message-sessions-02 Thread-Index: AcOjtCII4+vIq1T+TUK7ku/3bQi0/A== To: X-OriginalArrivalTime: 05 Nov 2003 15:47:36.0301 (UTC) FILETIME=[226549D0:01C3A3B4] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on message-sessions-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 17:47:36 +0200 Content-Transfer-Encoding: quoted-printable Some comments below are more serious that others. Please respond to the = ones that you think will cause some discussion is separate emails: - General: - Should we use URI in the text instead of URL? The RFC that is = referenced talks about URI (note if the references section, it wrongly = says URL) - Section 4:=20 - It should mention that a SEND request is also used as a keepalive = mechanism (it is stays that way)- - It mentions that a session is ended with a SIP BYE. It should say = that a session is ended using the signalling channel, for example a BYE = is used in sip =20 - This section also talks about inactivity timer, and says that that = hosting device invalidates the session state when timer expires. Why is = it just the hosting device? - Section 5.1: - Is this section normative? It have normative text like SHOULD and = SHOULD not. - Section 5.2: - Open issue: the attribute accept-type can be used to restrict the = use of a message session. So if a session was created to send mpeg = video. The accept-types attribute should only carry that mime-type. In = this way, the other endpoint does not use that session to send normal = messages. - Open issue: About avoiding timeouts for longer requests. Can we say = that if there are more than 1 session to the same endpoint, then keeping = any of the session alive keeps all the session alive. Eg: if you have a = session for text/plain and you create a second one to send a 5gb video = file, the text/plain session can be used to keepalive both sessions = since they are both to the same remote end. - Section 6: - Reference to RFC 3264 is probably needed here. - I had trouble figuring out how to send a second offer after the = first offer/answer exchange, for example to add a new mime type of to = add a new session. How does the new offer look like? Do we need to = include the session attribute carrying the session URI again? What do we = set the direction attribute to, if set at all in the second offer? Some = text and examples for this issue is needed. - Section 6.1: - The example is missing the accept-types attribute. - Section 6.3: - the BNF provided allows accept-types to have multiple *. eg: = a=3Daccept-types: * * * It should be fixed to something like:=20 accept-types =3D accept-types-label ":" format-list accept-types-label =3D "accept-types" format-list =3D "*" / format-entries format-entries =3D format-entry *( SP format-entry) format-entry =3D (type "/" subtype) type =3D token subtype =3D token - Need to reference the ABNF RFC - This section should mention that the offerer should use the = accept-types in the answer to send. - Section 6.4: - "format entries from the m-line SHOULD NOT be repeated in this = attribute". Should say accept-types instead of m-lines. - Section 7.1: - msrp_url =3D "msrp" ":" "//" [userinfo] hostport ["/' resource] ^^^ - @ is missing after userinfo - Should include server in the BNF since the text mentions server = many times, but its not to be seen in the BNF. So BNF would look like: msrp_url =3D "msrp" ":" "//" server ["/" resource] server =3D [userinfo "@"] hostport resource =3D 1*unreserved - Should mandate the resource when the msrp URI is present in an SDP = offer - Section 7.1.2: - Why is there text describing the use of SRV if no port is present? = The port is mandatory and therefore resolving should fail if no port is = present. INVITE requests would then be rejected. If we want SRV, then we = need to relax the MUST for port. - Section 7.4.1: - The last step before section 7.4.2 talks about Exp header. That = should not be there. There is no Exp header in a 200 response to a = visit. - Section 7.4.3: - In step 5 "The endpoint MAY attempt to send the message content = again" Should we remove this text? If the message sending fails, so be = it. The user can choose to send it again. This avoids the very large = message being sent again (long messages have the potential to falsely = timing out and the sender gets a 500 response). - Open issue: NO. - Section 7.4.4: - an INVITE request can also terminate a message session (port 0). = That should be noted along side the SIP BYE example. Otherwise = implementers will think that only a BYE can terminate a message session. - About when to stop sending responses to SEND request. I would = require that the initiator of the BYE (or any signalling request that = terminates the message session) should continue to send 200 responses to = SENDs until it has received a 200 for the SIP BYE. The recipient of the = SIP BYE should cease responding to SENDs as soon as it sent a 200 for = the SIP BYE. This allows more outstanding SENDs to complete. - Section 7.4.5: - Open issue: I don't understand the open issue. - "Each endpoint MUST keep a similar timer..." This sounds like a = third timer is present. Need to better tie this paragraph with the one = before it. - Section 7.5.1: - Steps for a Relay receiving a BIND request. Step 3 refers to = section 7.4.5, but that section talks about inactivity timer. - How dies the host communicate the pre-visit timer to the visitor? - Steps for a Relay receiving a VISIT request. The last step should = mention that the pre-visit timer is no longer valid. - Section 7.7.2: - Need to mention that SEND is also used for keepalive. Or = preferably, we can define an new method like KEEPALIVE as been = discussed. If not, then the SHOULD contain MIME should be relaxed. - Section 8: - Many examples don't have the CFLF between header and body in MSRP = messages. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 10:48:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10804 for ; Wed, 5 Nov 2003 10:48:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPtA-00010J-3m for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 10:48:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Fm855003853 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 10:48:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPt9-0000zs-Vb for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 10:48:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10765; Wed, 5 Nov 2003 10:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPt7-000627-00; Wed, 05 Nov 2003 10:48:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHPt6-000624-00; Wed, 05 Nov 2003 10:48:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPt2-0000wP-Pk; Wed, 05 Nov 2003 10:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHPsj-0000wE-9Q for simple@optimus.ietf.org; Wed, 05 Nov 2003 10:47:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10762 for ; Wed, 5 Nov 2003 10:47:27 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHPsg-000620-00 for simple@ietf.org; Wed, 05 Nov 2003 10:47:38 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHPsg-00061s-00 for simple@ietf.org; Wed, 05 Nov 2003 10:47:38 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA5FlaY12527 for ; Wed, 5 Nov 2003 17:47:36 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Nov 2003 17:47:36 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 5 Nov 2003 17:47:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Thread-Topic: Comments on message-sessions-02 Thread-Index: AcOjtCII4+vIq1T+TUK7ku/3bQi0/A== To: X-OriginalArrivalTime: 05 Nov 2003 15:47:36.0301 (UTC) FILETIME=[226549D0:01C3A3B4] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Comments on message-sessions-02 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 5 Nov 2003 17:47:36 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Some comments below are more serious that others. Please respond to the = ones that you think will cause some discussion is separate emails: - General: - Should we use URI in the text instead of URL? The RFC that is = referenced talks about URI (note if the references section, it wrongly = says URL) - Section 4:=20 - It should mention that a SEND request is also used as a keepalive = mechanism (it is stays that way)- - It mentions that a session is ended with a SIP BYE. It should say = that a session is ended using the signalling channel, for example a BYE = is used in sip =20 - This section also talks about inactivity timer, and says that that = hosting device invalidates the session state when timer expires. Why is = it just the hosting device? - Section 5.1: - Is this section normative? It have normative text like SHOULD and = SHOULD not. - Section 5.2: - Open issue: the attribute accept-type can be used to restrict the = use of a message session. So if a session was created to send mpeg = video. The accept-types attribute should only carry that mime-type. In = this way, the other endpoint does not use that session to send normal = messages. - Open issue: About avoiding timeouts for longer requests. Can we say = that if there are more than 1 session to the same endpoint, then keeping = any of the session alive keeps all the session alive. Eg: if you have a = session for text/plain and you create a second one to send a 5gb video = file, the text/plain session can be used to keepalive both sessions = since they are both to the same remote end. - Section 6: - Reference to RFC 3264 is probably needed here. - I had trouble figuring out how to send a second offer after the = first offer/answer exchange, for example to add a new mime type of to = add a new session. How does the new offer look like? Do we need to = include the session attribute carrying the session URI again? What do we = set the direction attribute to, if set at all in the second offer? Some = text and examples for this issue is needed. - Section 6.1: - The example is missing the accept-types attribute. - Section 6.3: - the BNF provided allows accept-types to have multiple *. eg: = a=3Daccept-types: * * * It should be fixed to something like:=20 accept-types =3D accept-types-label ":" format-list accept-types-label =3D "accept-types" format-list =3D "*" / format-entries format-entries =3D format-entry *( SP format-entry) format-entry =3D (type "/" subtype) type =3D token subtype =3D token - Need to reference the ABNF RFC - This section should mention that the offerer should use the = accept-types in the answer to send. - Section 6.4: - "format entries from the m-line SHOULD NOT be repeated in this = attribute". Should say accept-types instead of m-lines. - Section 7.1: - msrp_url =3D "msrp" ":" "//" [userinfo] hostport ["/' resource] ^^^ - @ is missing after userinfo - Should include server in the BNF since the text mentions server = many times, but its not to be seen in the BNF. So BNF would look like: msrp_url =3D "msrp" ":" "//" server ["/" resource] server =3D [userinfo "@"] hostport resource =3D 1*unreserved - Should mandate the resource when the msrp URI is present in an SDP = offer - Section 7.1.2: - Why is there text describing the use of SRV if no port is present? = The port is mandatory and therefore resolving should fail if no port is = present. INVITE requests would then be rejected. If we want SRV, then we = need to relax the MUST for port. - Section 7.4.1: - The last step before section 7.4.2 talks about Exp header. That = should not be there. There is no Exp header in a 200 response to a = visit. - Section 7.4.3: - In step 5 "The endpoint MAY attempt to send the message content = again" Should we remove this text? If the message sending fails, so be = it. The user can choose to send it again. This avoids the very large = message being sent again (long messages have the potential to falsely = timing out and the sender gets a 500 response). - Open issue: NO. - Section 7.4.4: - an INVITE request can also terminate a message session (port 0). = That should be noted along side the SIP BYE example. Otherwise = implementers will think that only a BYE can terminate a message session. - About when to stop sending responses to SEND request. I would = require that the initiator of the BYE (or any signalling request that = terminates the message session) should continue to send 200 responses to = SENDs until it has received a 200 for the SIP BYE. The recipient of the = SIP BYE should cease responding to SENDs as soon as it sent a 200 for = the SIP BYE. This allows more outstanding SENDs to complete. - Section 7.4.5: - Open issue: I don't understand the open issue. - "Each endpoint MUST keep a similar timer..." This sounds like a = third timer is present. Need to better tie this paragraph with the one = before it. - Section 7.5.1: - Steps for a Relay receiving a BIND request. Step 3 refers to = section 7.4.5, but that section talks about inactivity timer. - How dies the host communicate the pre-visit timer to the visitor? - Steps for a Relay receiving a VISIT request. The last step should = mention that the pre-visit timer is no longer valid. - Section 7.7.2: - Need to mention that SEND is also used for keepalive. Or = preferably, we can define an new method like KEEPALIVE as been = discussed. If not, then the SHOULD contain MIME should be relaxed. - Section 8: - Many examples don't have the CFLF between header and body in MSRP = messages. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 14:17:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17942; Wed, 5 Nov 2003 14:17:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTAI-00015j-00; Wed, 05 Nov 2003 14:18:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTAI-00015g-00; Wed, 05 Nov 2003 14:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTAI-0005YL-4y; Wed, 05 Nov 2003 14:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTAE-0005Y7-SU for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:17:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17936 for ; Wed, 5 Nov 2003 14:17:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTAC-00015X-00 for simple@ietf.org; Wed, 05 Nov 2003 14:17:56 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTAC-00015U-00 for simple@ietf.org; Wed, 05 Nov 2003 14:17:56 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JHNAt015316; Wed, 5 Nov 2003 11:17:23 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18341; Wed, 5 Nov 2003 14:17:20 -0500 (EST) Message-ID: <3FA94CC0.4070709@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:17:20 -0500 Content-Transfer-Encoding: 7bit Hisham, I'm glad you did such a careful review. I've commented on a few things below, and also split some others off into separate threads. I edited out all the stuff I didn't want to comment on. Paul hisham.khartabil@nokia.com wrote: > > - Section 4: > - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip Yes, I agree. Normally I would expect people to know this sort of thing. But better to be safe. We may get some people new to sip who are only doing MSRP. > - Section 5.2: > - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mime-type. In this way, the other endpoint does not use that session to send normal messages. That is a possibility, but it doesn't totally solve the problem. The mere fact that the accept-type is mpeg doesn't say that this is to be treated as a file transfer and stored rather than being rendered as it is received. Also, it might prove useful to keep the 2nd session around, once established, in case other file transfers are requested. But they might turn out to be of a different file type. > - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session alive. Eg: if you have a session for text/plain and you create a second one to send a 5gb video file, the text/plain session can be used to keepalive both sessions since they are both to the same remote end. This sounds like a *really bad* idea. This only works if the code processing the multiple streams is closely coordinated in some way. One end can't presume to know that will be the case at the other end. We have discussed other, I think better, ways of dealing with the timeouts. > - Section 6: > - Reference to RFC 3264 is probably needed here. > - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we need to include the session attribute carrying the session URI again? What do we set the direction attribute to, if set at all in the second offer? Some text and examples for this issue is needed. These are really good questions, worth a separate thread. > - Section 6.3: > - the BNF provided allows accept-types to have multiple *. eg: a=accept-types: * * * > It should be fixed to something like: > > accept-types = accept-types-label ":" format-list > accept-types-label = "accept-types" > format-list = "*" / format-entries > format-entries = format-entry *( SP format-entry) > format-entry = (type "/" subtype) > type = token > subtype = token I thought we were changing to having *only* a "*" on the m-line and doing all the rest with attributes. > - Section 7.4.3: > - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the very large message being sent again (long messages have the potential to falsely timing out and the sender gets a 500 response). > - Open issue: NO. Another one that deserves its own topic. > - Section 7.4.4: > - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message session. Yes. And UPDATE is yet another way to accomplish this. > - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200 responses to SENDs until it has received a 200 for the SIP BYE. The recipient of the SIP BYE should cease responding to SENDs as soon as it sent a 200 for the SIP BYE. This allows more outstanding SENDs to complete. Another separate thread > - Section 7.4.5: > - Open issue: I don't understand the open issue. > - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it. I also find it confusing how many timers there are, and where. I think it is that each endpoint has one, while a relay has two - one on each side. But that isn't so clear. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 14:18:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17967 for ; Wed, 5 Nov 2003 14:18:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTAM-0005ZF-3F for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 14:18:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JI6jo021397 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 14:18:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTAL-0005Z2-W6 for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:18:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17942; Wed, 5 Nov 2003 14:17:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTAI-00015j-00; Wed, 05 Nov 2003 14:18:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTAI-00015g-00; Wed, 05 Nov 2003 14:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTAI-0005YL-4y; Wed, 05 Nov 2003 14:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTAE-0005Y7-SU for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:17:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17936 for ; Wed, 5 Nov 2003 14:17:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTAC-00015X-00 for simple@ietf.org; Wed, 05 Nov 2003 14:17:56 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTAC-00015U-00 for simple@ietf.org; Wed, 05 Nov 2003 14:17:56 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JHNAt015316; Wed, 5 Nov 2003 11:17:23 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18341; Wed, 5 Nov 2003 14:17:20 -0500 (EST) Message-ID: <3FA94CC0.4070709@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:17:20 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, I'm glad you did such a careful review. I've commented on a few things below, and also split some others off into separate threads. I edited out all the stuff I didn't want to comment on. Paul hisham.khartabil@nokia.com wrote: > > - Section 4: > - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip Yes, I agree. Normally I would expect people to know this sort of thing. But better to be safe. We may get some people new to sip who are only doing MSRP. > - Section 5.2: > - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mime-type. In this way, the other endpoint does not use that session to send normal messages. That is a possibility, but it doesn't totally solve the problem. The mere fact that the accept-type is mpeg doesn't say that this is to be treated as a file transfer and stored rather than being rendered as it is received. Also, it might prove useful to keep the 2nd session around, once established, in case other file transfers are requested. But they might turn out to be of a different file type. > - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session alive. Eg: if you have a session for text/plain and you create a second one to send a 5gb video file, the text/plain session can be used to keepalive both sessions since they are both to the same remote end. This sounds like a *really bad* idea. This only works if the code processing the multiple streams is closely coordinated in some way. One end can't presume to know that will be the case at the other end. We have discussed other, I think better, ways of dealing with the timeouts. > - Section 6: > - Reference to RFC 3264 is probably needed here. > - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we need to include the session attribute carrying the session URI again? What do we set the direction attribute to, if set at all in the second offer? Some text and examples for this issue is needed. These are really good questions, worth a separate thread. > - Section 6.3: > - the BNF provided allows accept-types to have multiple *. eg: a=accept-types: * * * > It should be fixed to something like: > > accept-types = accept-types-label ":" format-list > accept-types-label = "accept-types" > format-list = "*" / format-entries > format-entries = format-entry *( SP format-entry) > format-entry = (type "/" subtype) > type = token > subtype = token I thought we were changing to having *only* a "*" on the m-line and doing all the rest with attributes. > - Section 7.4.3: > - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the very large message being sent again (long messages have the potential to falsely timing out and the sender gets a 500 response). > - Open issue: NO. Another one that deserves its own topic. > - Section 7.4.4: > - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message session. Yes. And UPDATE is yet another way to accomplish this. > - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200 responses to SENDs until it has received a 200 for the SIP BYE. The recipient of the SIP BYE should cease responding to SENDs as soon as it sent a 200 for the SIP BYE. This allows more outstanding SENDs to complete. Another separate thread > - Section 7.4.5: > - Open issue: I don't understand the open issue. > - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it. I also find it confusing how many timers there are, and where. I think it is that each endpoint has one, while a relay has two - one on each side. But that isn't so clear. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 14:19:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18017; Wed, 5 Nov 2003 14:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTCF-00016i-00; Wed, 05 Nov 2003 14:20:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTCE-00016f-00; Wed, 05 Nov 2003 14:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTCE-0005hP-Nn; Wed, 05 Nov 2003 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTBE-0005ew-5R for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:19:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17983 for ; Wed, 5 Nov 2003 14:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000164-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000160-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:19:00 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JIKDd008955; Wed, 5 Nov 2003 11:18:20 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18458; Wed, 5 Nov 2003 14:18:19 -0500 (EST) Message-ID: <3FA94CFB.70102@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - reinvite behavior References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:18:19 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 6: > - Reference to RFC 3264 is probably needed here. > - I had trouble figuring out how to send a second offer after the > first offer/answer exchange, for example to add a new mime type > of to add a new session. How does the new offer look like? Even before discussing that, it is important to be clear what an offer/answer that doesn't change *anything* looks like. For instance this might occur when attempting to do a session timer refresh, or when there is another media session (e.g. voice) that is being changed but this one isn't. Normally, you expect that the last SDP can be exchanged without change. This works pretty simply for RTP and UDP. But it has presented some issues in comedia, and may do so here as well. The question is how to decide if this is a request to tear down the old session and build a new one, or simply to leave the old one alone. For instance, suppose I am the visitor in the current session, and I have experienced a timeout - I sent something and got no response. I would like to try to remedy the situation. But I still need to be the visitor. So what can I do? I can send a reinvite. It will presumably look like my last one. If the other end is still present and receives the reinvite, I perhaps would like him to tear down the existing stream and offer me a chance to visit a new one. > Do we need to include the session attribute carrying the session URI again? > What do we set the direction attribute to, if set at all in the second offer? I think the answer should be something like: If the visitor initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with a=direction:active, even if direction:both had been used previously. Then if the answerer also prefers to continue with the existing session, it should answer with direction:passive and include the old session URI. Receipt of an answer with the old session URI is a signal to the offerer to continue using the existing session. OTOH, if the answerer prefers to switch to a new media session, it should respond with a new session URI. If the host initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with direction:passive and the old session URI. Then if the answerer prefers also prefers to continue with the existing session, it should answer with direction:active, and just continue using the old session. If the answerer prefers to switch to a new media session it can either accept this as just mentioned or refuse it by setting the port to zero. Then it can initiate a new offer/answer cycle. If the host initiates a new offer/answer cycle and wants to switch to a new media session, it may send an offer with a new session URI and with a direction of either passive or both. Either way is clear. All actions are as if starting from scratch. If the visitor initiates a new offer/answer cycle and wants to switch to a new media session, and if it is capable of acting as host, it can do as in the prior paragraph. If it cannot, then the best it can do is to send an offer with a port of zero to terminate the existing session. It can then then do yet another offer/answer to establish a new session. Or, it can combine the two steps - setting the port to zero for the existing session but proposing a new 2nd session in the same offer. [Is more needed to cover the two relay case???] A reinvite to make a change like adding a new mime type, that doesn't require changing the connections, can be the same as above, but changing the attributes appropriately. However, just as there are rules about changing codecs in reinvites, there probably should be rules about changing supported mime types in existing MSRP sessions. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 14:20:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18041 for ; Wed, 5 Nov 2003 14:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTCJ-0005jX-Ns for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 14:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JK7iT022027 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 14:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTCI-0005j8-8S for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:20:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18017; Wed, 5 Nov 2003 14:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTCF-00016i-00; Wed, 05 Nov 2003 14:20:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTCE-00016f-00; Wed, 05 Nov 2003 14:20:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTCE-0005hP-Nn; Wed, 05 Nov 2003 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTBE-0005ew-5R for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:19:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17983 for ; Wed, 5 Nov 2003 14:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000164-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000160-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:19:00 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JIKDd008955; Wed, 5 Nov 2003 11:18:20 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18458; Wed, 5 Nov 2003 14:18:19 -0500 (EST) Message-ID: <3FA94CFB.70102@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - reinvite behavior References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:18:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 6: > - Reference to RFC 3264 is probably needed here. > - I had trouble figuring out how to send a second offer after the > first offer/answer exchange, for example to add a new mime type > of to add a new session. How does the new offer look like? Even before discussing that, it is important to be clear what an offer/answer that doesn't change *anything* looks like. For instance this might occur when attempting to do a session timer refresh, or when there is another media session (e.g. voice) that is being changed but this one isn't. Normally, you expect that the last SDP can be exchanged without change. This works pretty simply for RTP and UDP. But it has presented some issues in comedia, and may do so here as well. The question is how to decide if this is a request to tear down the old session and build a new one, or simply to leave the old one alone. For instance, suppose I am the visitor in the current session, and I have experienced a timeout - I sent something and got no response. I would like to try to remedy the situation. But I still need to be the visitor. So what can I do? I can send a reinvite. It will presumably look like my last one. If the other end is still present and receives the reinvite, I perhaps would like him to tear down the existing stream and offer me a chance to visit a new one. > Do we need to include the session attribute carrying the session URI again? > What do we set the direction attribute to, if set at all in the second offer? I think the answer should be something like: If the visitor initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with a=direction:active, even if direction:both had been used previously. Then if the answerer also prefers to continue with the existing session, it should answer with direction:passive and include the old session URI. Receipt of an answer with the old session URI is a signal to the offerer to continue using the existing session. OTOH, if the answerer prefers to switch to a new media session, it should respond with a new session URI. If the host initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with direction:passive and the old session URI. Then if the answerer prefers also prefers to continue with the existing session, it should answer with direction:active, and just continue using the old session. If the answerer prefers to switch to a new media session it can either accept this as just mentioned or refuse it by setting the port to zero. Then it can initiate a new offer/answer cycle. If the host initiates a new offer/answer cycle and wants to switch to a new media session, it may send an offer with a new session URI and with a direction of either passive or both. Either way is clear. All actions are as if starting from scratch. If the visitor initiates a new offer/answer cycle and wants to switch to a new media session, and if it is capable of acting as host, it can do as in the prior paragraph. If it cannot, then the best it can do is to send an offer with a port of zero to terminate the existing session. It can then then do yet another offer/answer to establish a new session. Or, it can combine the two steps - setting the port to zero for the existing session but proposing a new 2nd session in the same offer. [Is more needed to cover the two relay case???] A reinvite to make a change like adding a new mime type, that doesn't require changing the connections, can be the same as above, but changing the attributes appropriately. However, just as there are rules about changing codecs in reinvites, there probably should be rules about changing supported mime types in existing MSRP sessions. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 14:22:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18155; Wed, 5 Nov 2003 14:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTF7-00019V-00; Wed, 05 Nov 2003 14:23:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTF7-00019S-00; Wed, 05 Nov 2003 14:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTF7-00065k-Kq; Wed, 05 Nov 2003 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTES-00064e-2l for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:22:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18142 for ; Wed, 5 Nov 2003 14:22:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTEP-000198-00 for simple@ietf.org; Wed, 05 Nov 2003 14:22:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTEP-00018a-00 for simple@ietf.org; Wed, 05 Nov 2003 14:22:17 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:22:20 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JLgAv020726; Wed, 5 Nov 2003 11:21:45 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18850; Wed, 5 Nov 2003 14:21:42 -0500 (EST) Message-ID: <3FA94DC6.7020400@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:21:42 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 7.4.3: > - In step 5 "The endpoint MAY attempt to send the message content again" > Should we remove this text? If the message sending fails, so be it. > The user can choose to send it again. This avoids the very large message > being sent again (long messages have the potential to falsely timing out > and the sender gets a 500 response). I agree this should go. We may want to discuss possibility of establishing a replacement media session and then retrying the message there. In that case I think we perhaps should make it permissible for the retry to use the same TR-ID. It is then optional whether the recipient detects the duplicate or not. This addresses the case where a relay crashes in an ungraceful way. > - Open issue: NO. I guess what I am proposing is YES, but with a weak mechanism - neither side is *required* to enable duplicate suppression, but the mechanism is there if both sides choose to use it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 14:23:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18182 for ; Wed, 5 Nov 2003 14:23:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTFB-00066o-0X for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 14:23:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JN4dx023476 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 14:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTFA-00066Z-Sj for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:23:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18155; Wed, 5 Nov 2003 14:22:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTF7-00019V-00; Wed, 05 Nov 2003 14:23:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTF7-00019S-00; Wed, 05 Nov 2003 14:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTF7-00065k-Kq; Wed, 05 Nov 2003 14:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTES-00064e-2l for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:22:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18142 for ; Wed, 5 Nov 2003 14:22:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTEP-000198-00 for simple@ietf.org; Wed, 05 Nov 2003 14:22:17 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTEP-00018a-00 for simple@ietf.org; Wed, 05 Nov 2003 14:22:17 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:22:20 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JLgAv020726; Wed, 5 Nov 2003 11:21:45 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18850; Wed, 5 Nov 2003 14:21:42 -0500 (EST) Message-ID: <3FA94DC6.7020400@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:21:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 7.4.3: > - In step 5 "The endpoint MAY attempt to send the message content again" > Should we remove this text? If the message sending fails, so be it. > The user can choose to send it again. This avoids the very large message > being sent again (long messages have the potential to falsely timing out > and the sender gets a 500 response). I agree this should go. We may want to discuss possibility of establishing a replacement media session and then retrying the message there. In that case I think we perhaps should make it permissible for the retry to use the same TR-ID. It is then optional whether the recipient detects the duplicate or not. This addresses the case where a relay crashes in an ungraceful way. > - Open issue: NO. I guess what I am proposing is YES, but with a weak mechanism - neither side is *required* to enable duplicate suppression, but the mechanism is there if both sides choose to use it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 5 14:30:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18851; Wed, 5 Nov 2003 14:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTMs-0001QE-00; Wed, 05 Nov 2003 14:31:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTMs-0001QB-00; Wed, 05 Nov 2003 14:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMt-0006vp-2y; Wed, 05 Nov 2003 14:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMn-0006up-RR for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:30:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18845 for ; Wed, 5 Nov 2003 14:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTMl-0001Pp-00 for simple@ietf.org; Wed, 05 Nov 2003 14:30:55 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTMk-0001Ol-00 for simple@ietf.org; Wed, 05 Nov 2003 14:30:54 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:30:58 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JUMAt001958; Wed, 5 Nov 2003 11:30:22 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT19984; Wed, 5 Nov 2003 14:30:21 -0500 (EST) Message-ID: <3FA94FCD.3000100@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02- ending a session References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:30:21 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 7.4.4: > - About when to stop sending responses to SEND request. > I would require that the initiator of the BYE > (or any signalling request that terminates the message session) > should continue to send 200 responses to SENDs until it has > received a 200 for the SIP BYE. The recipient of the SIP BYE > should cease responding to SENDs as soon as it sent a 200 for > the SIP BYE. This allows more outstanding SENDs to complete. I don't think this is good enough. Consider: X-----R------Y X has sent a large message, but for some reason R has been buffering it, so that none has reached Y. Y thinks things are idle, and sends a BYE. What should X do when it receives the BYE? It could wait for a response to its message for sending the 200 on the BYE. But if the message is large, the BYE might time out before the message fully arrives at Y so that Y may respond to it. Or X could send the the 200 for the BYE immediately. But then its less likely to get a response to the message. What X needs to know is whether the messages it has sent have been processed by the recipient. Its especially important to know this in a graceful shutdown case like this. I think the key is that in a graceful shutdown, a response must be sent for every message that is processed by the receiving end. Once having sent or received signaling initiating the shutdown of the session it may stop processing messages. Then, for the messages not processed, it may either send an error response of some sort, or else send no response. For this to be beneficial, both ends need to drain the connection, processing responses, as long as they have any unacknowledged messages outstanding. Message delivery failure will be minimized if both sides continue processing incoming messages, and sending responses to them, until an eof is received on the connection. This is even after the signaling is all completed. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 5 14:31:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18919 for ; Wed, 5 Nov 2003 14:31:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMw-0006y8-1d for simple-archive@odin.ietf.org; Wed, 05 Nov 2003 14:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5JV66S026782 for simple-archive@odin.ietf.org; Wed, 5 Nov 2003 14:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMv-0006xt-U3 for simple-web-archive@optimus.ietf.org; Wed, 05 Nov 2003 14:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18851; Wed, 5 Nov 2003 14:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTMs-0001QE-00; Wed, 05 Nov 2003 14:31:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHTMs-0001QB-00; Wed, 05 Nov 2003 14:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMt-0006vp-2y; Wed, 05 Nov 2003 14:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTMn-0006up-RR for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:30:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18845 for ; Wed, 5 Nov 2003 14:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTMl-0001Pp-00 for simple@ietf.org; Wed, 05 Nov 2003 14:30:55 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTMk-0001Ol-00 for simple@ietf.org; Wed, 05 Nov 2003 14:30:54 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:30:58 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JUMAt001958; Wed, 5 Nov 2003 11:30:22 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT19984; Wed, 5 Nov 2003 14:30:21 -0500 (EST) Message-ID: <3FA94FCD.3000100@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02- ending a session References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:30:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 7.4.4: > - About when to stop sending responses to SEND request. > I would require that the initiator of the BYE > (or any signalling request that terminates the message session) > should continue to send 200 responses to SENDs until it has > received a 200 for the SIP BYE. The recipient of the SIP BYE > should cease responding to SENDs as soon as it sent a 200 for > the SIP BYE. This allows more outstanding SENDs to complete. I don't think this is good enough. Consider: X-----R------Y X has sent a large message, but for some reason R has been buffering it, so that none has reached Y. Y thinks things are idle, and sends a BYE. What should X do when it receives the BYE? It could wait for a response to its message for sending the 200 on the BYE. But if the message is large, the BYE might time out before the message fully arrives at Y so that Y may respond to it. Or X could send the the 200 for the BYE immediately. But then its less likely to get a response to the message. What X needs to know is whether the messages it has sent have been processed by the recipient. Its especially important to know this in a graceful shutdown case like this. I think the key is that in a graceful shutdown, a response must be sent for every message that is processed by the receiving end. Once having sent or received signaling initiating the shutdown of the session it may stop processing messages. Then, for the messages not processed, it may either send an error response of some sort, or else send no response. For this to be beneficial, both ends need to drain the connection, processing responses, as long as they have any unacknowledged messages outstanding. Message delivery failure will be minimized if both sides continue processing incoming messages, and sending responses to them, until an eof is received on the connection. This is even after the signaling is all completed. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 04:41:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01047; Thu, 6 Nov 2003 04:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgda-0005lW-00; Thu, 06 Nov 2003 04:41:10 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgdY-0005k0-00; Thu, 06 Nov 2003 04:41:09 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgQf-0000xX-Jt; Thu, 06 Nov 2003 04:27:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgQE-0000RN-Kt; Thu, 06 Nov 2003 04:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgPr-0000Gt-1E for simple@optimus.ietf.org; Thu, 06 Nov 2003 04:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00449 for ; Thu, 6 Nov 2003 04:26:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgPn-0005Wq-00 for simple@ietf.org; Thu, 06 Nov 2003 04:26:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHgPm-0005Wn-00 for simple@ietf.org; Thu, 06 Nov 2003 04:26:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA69QtF27957 for ; Thu, 6 Nov 2003 11:26:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 11:26:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Nov 2003 11:26:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02- ending a session Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179738A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02- ending a session Thread-Index: AcOj00YjeW6AWw0wQYuJyR8OfRlqMQAc+8Vw To: Cc: X-OriginalArrivalTime: 06 Nov 2003 09:26:54.0843 (UTC) FILETIME=[1E3D24B0:01C3A448] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 11:26:54 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 05, 2003 9:30 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02- ending=20 > a session >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > > - Section 7.4.4: > > - About when to stop sending responses to SEND request. > > I would require that the initiator of the BYE > > (or any signalling request that terminates the=20 > message session) > > should continue to send 200 responses to SENDs until it has > > received a 200 for the SIP BYE. The recipient of the SIP BYE > > should cease responding to SENDs as soon as it sent a 200 for > > the SIP BYE. This allows more outstanding SENDs to complete. >=20 > I don't think this is good enough. Consider: >=20 > X-----R------Y >=20 > X has sent a large message, but for some reason R has been=20 > buffering it,=20 > so that none has reached Y. Y thinks things are idle, and sends a BYE. >=20 > What should X do when it receives the BYE? It could wait for=20 > a response=20 > to its message for sending the 200 on the BYE. But if the message is=20 > large, the BYE might time out before the message fully=20 > arrives at Y so=20 > that Y may respond to it. Or X could send the the 200 for the BYE=20 > immediately. But then its less likely to get a response to=20 > the message. >=20 > What X needs to know is whether the messages it has sent have been=20 > processed by the recipient. Its especially important to know=20 > this in a=20 > graceful shutdown case like this. >=20 > I think the key is that in a graceful shutdown, a response=20 > must be sent=20 > for every message that is processed by the receiving end. Once having=20 > sent or received signaling initiating the shutdown of the=20 > session it may=20 > stop processing messages. Then, for the messages not=20 > processed, it may=20 > either send an error response of some sort, or else send no response. >=20 > For this to be beneficial, both ends need to drain the connection,=20 > processing responses, as long as they have any unacknowledged=20 > messages=20 > outstanding. >=20 > Message delivery failure will be minimized if both sides continue=20 > processing incoming messages, and sending responses to them, until an=20 > eof is received on the connection. This is even after the=20 > signaling is=20 > all completed. This might work, but you have to make the restriction that an endpoint = MUST NOT initiate any further SEND requests once it has sent or received = a message session termination request (a SIP BYE for example). Also, and endpoint MUST NOT terminate a message session if it is still = receiving a large message. It MUST first send a 500 to that message = indicating to the relay or the peer endpoint that it does not wish to = continue receiving this large message. It can then terminate the = session. /Hisham >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 04:41:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01144 for ; Thu, 6 Nov 2003 04:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgdg-0001eG-BN for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 04:41:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69fGPt006322 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 04:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgde-0001dU-CB for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 04:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01047; Thu, 6 Nov 2003 04:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgda-0005lW-00; Thu, 06 Nov 2003 04:41:10 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgdY-0005k0-00; Thu, 06 Nov 2003 04:41:09 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgQf-0000xX-Jt; Thu, 06 Nov 2003 04:27:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgQE-0000RN-Kt; Thu, 06 Nov 2003 04:27:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgPr-0000Gt-1E for simple@optimus.ietf.org; Thu, 06 Nov 2003 04:26:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00449 for ; Thu, 6 Nov 2003 04:26:45 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgPn-0005Wq-00 for simple@ietf.org; Thu, 06 Nov 2003 04:26:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHgPm-0005Wn-00 for simple@ietf.org; Thu, 06 Nov 2003 04:26:54 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA69QtF27957 for ; Thu, 6 Nov 2003 11:26:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 11:26:55 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 6 Nov 2003 11:26:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02- ending a session Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179738A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02- ending a session Thread-Index: AcOj00YjeW6AWw0wQYuJyR8OfRlqMQAc+8Vw To: Cc: X-OriginalArrivalTime: 06 Nov 2003 09:26:54.0843 (UTC) FILETIME=[1E3D24B0:01C3A448] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 11:26:54 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 05, 2003 9:30 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02- ending=20 > a session >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > > - Section 7.4.4: > > - About when to stop sending responses to SEND request. > > I would require that the initiator of the BYE > > (or any signalling request that terminates the=20 > message session) > > should continue to send 200 responses to SENDs until it has > > received a 200 for the SIP BYE. The recipient of the SIP BYE > > should cease responding to SENDs as soon as it sent a 200 for > > the SIP BYE. This allows more outstanding SENDs to complete. >=20 > I don't think this is good enough. Consider: >=20 > X-----R------Y >=20 > X has sent a large message, but for some reason R has been=20 > buffering it,=20 > so that none has reached Y. Y thinks things are idle, and sends a BYE. >=20 > What should X do when it receives the BYE? It could wait for=20 > a response=20 > to its message for sending the 200 on the BYE. But if the message is=20 > large, the BYE might time out before the message fully=20 > arrives at Y so=20 > that Y may respond to it. Or X could send the the 200 for the BYE=20 > immediately. But then its less likely to get a response to=20 > the message. >=20 > What X needs to know is whether the messages it has sent have been=20 > processed by the recipient. Its especially important to know=20 > this in a=20 > graceful shutdown case like this. >=20 > I think the key is that in a graceful shutdown, a response=20 > must be sent=20 > for every message that is processed by the receiving end. Once having=20 > sent or received signaling initiating the shutdown of the=20 > session it may=20 > stop processing messages. Then, for the messages not=20 > processed, it may=20 > either send an error response of some sort, or else send no response. >=20 > For this to be beneficial, both ends need to drain the connection,=20 > processing responses, as long as they have any unacknowledged=20 > messages=20 > outstanding. >=20 > Message delivery failure will be minimized if both sides continue=20 > processing incoming messages, and sending responses to them, until an=20 > eof is received on the connection. This is even after the=20 > signaling is=20 > all completed. This might work, but you have to make the restriction that an endpoint = MUST NOT initiate any further SEND requests once it has sent or received = a message session termination request (a SIP BYE for example). Also, and endpoint MUST NOT terminate a message session if it is still = receiving a large message. It MUST first send a 500 to that message = indicating to the relay or the peer endpoint that it does not wish to = continue receiving this large message. It can then terminate the = session. /Hisham >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 04:42:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01203; Thu, 6 Nov 2003 04:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgea-0005ob-00; Thu, 06 Nov 2003 04:42:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgeY-0005nL-00; Thu, 06 Nov 2003 04:42:11 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgOS-0000tU-OY; Thu, 06 Nov 2003 04:25:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgO9-0008Bn-Dd; Thu, 06 Nov 2003 04:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHg6e-0006nY-SU for simple@optimus.ietf.org; Thu, 06 Nov 2003 04:07:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29686; Thu, 6 Nov 2003 04:06:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHg6c-0005EK-00; Thu, 06 Nov 2003 04:07:06 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AHg6b-0005EH-00; Thu, 06 Nov 2003 04:07:05 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hA6974V06963; Thu, 6 Nov 2003 10:07:04 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA696ws28297; Thu, 6 Nov 2003 10:06:59 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Nov 2003 10:06:43 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 10:06:48 +0100 hi jonathan, could you describe how the domain authorization procedure works? where do you get the domain part for the identifier. the problem we saw in the past was that you have to understand the structure of the identifier in order for it to work. ciao hannes btw, another small issue. the name of the authorization draft is very misleading. there is no need to contain the name xcap in there since the policies should actually be independent of xcap. i noticed the problem with the names in various discussions. people automatically think that those two belong together. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 04, 2003 2:06 AM > To: Henning Schulzrinne > Cc: Tschofenig Hannes; 'Rosen, Brian'; Simple WG; 'geopriv@ietf.org' > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > > > Henning Schulzrinne wrote: > > > [Starting clean...] > > > > There are two somewhat separate issues: > > > > (1) Splitting into domain and user components, i.e., we could have > > permissions that apply to all users in a domain and some > that apply to > > only specific users. That, by itself, does not break the > additive model, > > if specific users have at least the permissions of the > specific users > > within the domain. > > > > While I don't believe that, in practice, domain-specific > permissions are > > all that useful for organizations of non-trivial size, the model of > > "everybody within domain gets baseline permissions, special > people get > > more" seems plausible. > > In particular, this seems to be a common cases for many small to > medium enterprises, where "domain" is the domain of the enterprise. > > > > (2) I share Hannes concern about making exceptions on any field, > > including the user or domain match. I don't see the real-world > > motivation for this and it complicates the conceptual > model. (In the > > geopriv interim we discussed at length as to why blacklists are > > generally a bad idea, even with authentication, unless you > can guarantee > > that the bad guys you want to keep out can't change their verified > > identity to a new one.) > > I think this is a legitimate complaint for the case "accept anyone > EXCEPT for Joe". However, for the case "accept anyone from > example.com > EXCEPT Joe", I dont think this concern is applicable. There, > it is not > so easy for the user to change their identity to a new one. The > classic use case would be a company where I initially allow anyone in > my enterprise, but then this one bothersome employee keeps pestering > me for information every time I log in, and I want to put him on my > black list so he doesnt see my status anymore. This seems like a > legitimate case. > > Also, another case where except clauses make sense is where I want > different information provided to different people. For example, > everyone in my company sees my cell phone status and my PC status, > except for that annoying Joe again, who only sees my PC. > > My main point, however, is that none of my arguments above are > specific to presence as opposed to geopriv. If blacklists are bad for > geopriv, they are also bad for presence, and vice a versa. > > > > > > At one point, I thought the basic design principle was that > we weren't > > done until we couldn't *remove* any features - with policies, it's > > always tempting to pile on more and more "could be useful > somewhere" > > items, so I think proponents of particular items should be > held to a > > fairly high standard of proof as to why a particular feature is > > absolutely, positively necessary for a first version. In > the geopriv > > draft, we spend some time talking about future extensions > and how they > > are privacy-safe under certain baseline assumptions. We > can't anticipate > > all the things that we might need and the things that turn > out to be > > less than useful in practice, so I'd much rather start > clean and small > > and then expand based on implementation experience. We just > don't have a > > whole lot (if any) experience with policy languages or rule > sets in the > > IETF. > > I am with you on removing features, and as you can see have taken the > axe to xcap-auth in a pretty serious way. I am also totally in > agreement with the value of something being privacy-safe. I think the > concerns about except-clauses in the applies-to section only apply > when the except-clauses reference external lists. I see several > options there: > > (1) don't allow except clauses to reference external lists at all > > (2) allow them to reference lists present only on the same server > > (3) AND/OR if the list cannot be obtained, then the > permissions in the > associated statement are granted to NO ONE. > > > I believe that (1), (2,3) or (3) would make the except clause privacy > safe. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 04:42:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01239 for ; Thu, 6 Nov 2003 04:42:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgei-0001tD-3k for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 04:42:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69gKg5007259 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 04:42:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgeh-0001sw-Oi for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 04:42:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01203; Thu, 6 Nov 2003 04:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgea-0005ob-00; Thu, 06 Nov 2003 04:42:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgeY-0005nL-00; Thu, 06 Nov 2003 04:42:11 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgOS-0000tU-OY; Thu, 06 Nov 2003 04:25:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgO9-0008Bn-Dd; Thu, 06 Nov 2003 04:25:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHg6e-0006nY-SU for simple@optimus.ietf.org; Thu, 06 Nov 2003 04:07:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29686; Thu, 6 Nov 2003 04:06:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHg6c-0005EK-00; Thu, 06 Nov 2003 04:07:06 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AHg6b-0005EH-00; Thu, 06 Nov 2003 04:07:05 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hA6974V06963; Thu, 6 Nov 2003 10:07:04 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA696ws28297; Thu, 6 Nov 2003 10:06:59 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Thu, 6 Nov 2003 10:06:43 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Henning Schulzrinne Cc: "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 10:06:48 +0100 hi jonathan, could you describe how the domain authorization procedure works? where do you get the domain part for the identifier. the problem we saw in the past was that you have to understand the structure of the identifier in order for it to work. ciao hannes btw, another small issue. the name of the authorization draft is very misleading. there is no need to contain the name xcap in there since the policies should actually be independent of xcap. i noticed the problem with the names in various discussions. people automatically think that those two belong together. > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, November 04, 2003 2:06 AM > To: Henning Schulzrinne > Cc: Tschofenig Hannes; 'Rosen, Brian'; Simple WG; 'geopriv@ietf.org' > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > > > Henning Schulzrinne wrote: > > > [Starting clean...] > > > > There are two somewhat separate issues: > > > > (1) Splitting into domain and user components, i.e., we could have > > permissions that apply to all users in a domain and some > that apply to > > only specific users. That, by itself, does not break the > additive model, > > if specific users have at least the permissions of the > specific users > > within the domain. > > > > While I don't believe that, in practice, domain-specific > permissions are > > all that useful for organizations of non-trivial size, the model of > > "everybody within domain gets baseline permissions, special > people get > > more" seems plausible. > > In particular, this seems to be a common cases for many small to > medium enterprises, where "domain" is the domain of the enterprise. > > > > (2) I share Hannes concern about making exceptions on any field, > > including the user or domain match. I don't see the real-world > > motivation for this and it complicates the conceptual > model. (In the > > geopriv interim we discussed at length as to why blacklists are > > generally a bad idea, even with authentication, unless you > can guarantee > > that the bad guys you want to keep out can't change their verified > > identity to a new one.) > > I think this is a legitimate complaint for the case "accept anyone > EXCEPT for Joe". However, for the case "accept anyone from > example.com > EXCEPT Joe", I dont think this concern is applicable. There, > it is not > so easy for the user to change their identity to a new one. The > classic use case would be a company where I initially allow anyone in > my enterprise, but then this one bothersome employee keeps pestering > me for information every time I log in, and I want to put him on my > black list so he doesnt see my status anymore. This seems like a > legitimate case. > > Also, another case where except clauses make sense is where I want > different information provided to different people. For example, > everyone in my company sees my cell phone status and my PC status, > except for that annoying Joe again, who only sees my PC. > > My main point, however, is that none of my arguments above are > specific to presence as opposed to geopriv. If blacklists are bad for > geopriv, they are also bad for presence, and vice a versa. > > > > > > At one point, I thought the basic design principle was that > we weren't > > done until we couldn't *remove* any features - with policies, it's > > always tempting to pile on more and more "could be useful > somewhere" > > items, so I think proponents of particular items should be > held to a > > fairly high standard of proof as to why a particular feature is > > absolutely, positively necessary for a first version. In > the geopriv > > draft, we spend some time talking about future extensions > and how they > > are privacy-safe under certain baseline assumptions. We > can't anticipate > > all the things that we might need and the things that turn > out to be > > less than useful in practice, so I'd much rather start > clean and small > > and then expand based on implementation experience. We just > don't have a > > whole lot (if any) experience with policy languages or rule > sets in the > > IETF. > > I am with you on removing features, and as you can see have taken the > axe to xcap-auth in a pretty serious way. I am also totally in > agreement with the value of something being privacy-safe. I think the > concerns about except-clauses in the applies-to section only apply > when the except-clauses reference external lists. I see several > options there: > > (1) don't allow except clauses to reference external lists at all > > (2) allow them to reference lists present only on the same server > > (3) AND/OR if the list cannot be obtained, then the > permissions in the > associated statement are granted to NO ONE. > > > I believe that (1), (2,3) or (3) would make the except clause privacy > safe. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 04:45:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01503; Thu, 6 Nov 2003 04:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHghw-0005xt-00; Thu, 06 Nov 2003 04:45:40 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgdB-0005gw-00; Thu, 06 Nov 2003 04:40:45 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgV2-0001EW-39; Thu, 06 Nov 2003 04:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgUm-0000pN-AK; Thu, 06 Nov 2003 04:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgUb-0000p0-9S for simple@optimus.ietf.org; Thu, 06 Nov 2003 04:31:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00655 for ; Thu, 6 Nov 2003 04:31:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgUY-0005cZ-00 for simple@ietf.org; Thu, 06 Nov 2003 04:31:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHgUX-0005cT-00 for simple@ietf.org; Thu, 06 Nov 2003 04:31:49 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA69VnY20141 for ; Thu, 6 Nov 2003 11:31:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 11:31:47 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 11:31:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179738B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOj0jOsec/HSHC0RES5qYDHggjSaQAdf6VA To: Cc: X-OriginalArrivalTime: 06 Nov 2003 09:31:48.0580 (UTC) FILETIME=[CD51DA40:01C3A448] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 11:31:48 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 05, 2003 9:22 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > > - Section 7.4.3: > > - In step 5 "The endpoint MAY attempt to send the=20 > message content again" > > Should we remove this text? If the message sending=20 > fails, so be it. > > The user can choose to send it again. This avoids the=20 > very large=20 > message > > being sent again (long messages have the potential to falsely=20 > timing out > > and the sender gets a 500 response). >=20 > I agree this should go. We may want to discuss possibility of=20 > establishing a replacement media session and then retrying=20 > the message=20 > there. In that case I think we perhaps should make it permissible for=20 > the retry to use the same TR-ID. It is then optional whether the=20 > recipient detects the duplicate or not. If I understand you correctly, you are suggesting that if a message = fails with a 500 or a timeout, then we create a new session and try = resending it there? If so, then I think I disagree. I think there should = not be any retransmission at all. The end user can choose to send the = message again, after he learns that the message did not really get = there. Also, you really want to tie TR-IDs across sessions? Regards, Hisham >=20 > This addresses the case where a relay crashes in an ungraceful way. >=20 > > - Open issue: NO. >=20 > I guess what I am proposing is YES, but with a weak mechanism=20 > - neither=20 > side is *required* to enable duplicate suppression, but the=20 > mechanism is=20 > there if both sides choose to use it. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 04:46:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01668 for ; Thu, 6 Nov 2003 04:46:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgi1-000244-CY for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 04:45:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA69jidB007922 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 04:45:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgi0-00023a-8Y for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 04:45:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01503; Thu, 6 Nov 2003 04:45:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHghw-0005xt-00; Thu, 06 Nov 2003 04:45:40 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHgdB-0005gw-00; Thu, 06 Nov 2003 04:40:45 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHgV2-0001EW-39; Thu, 06 Nov 2003 04:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgUm-0000pN-AK; Thu, 06 Nov 2003 04:32:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHgUb-0000p0-9S for simple@optimus.ietf.org; Thu, 06 Nov 2003 04:31:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00655 for ; Thu, 6 Nov 2003 04:31:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHgUY-0005cZ-00 for simple@ietf.org; Thu, 06 Nov 2003 04:31:50 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHgUX-0005cT-00 for simple@ietf.org; Thu, 06 Nov 2003 04:31:49 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA69VnY20141 for ; Thu, 6 Nov 2003 11:31:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 11:31:47 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 11:31:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179738B@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOj0jOsec/HSHC0RES5qYDHggjSaQAdf6VA To: Cc: X-OriginalArrivalTime: 06 Nov 2003 09:31:48.0580 (UTC) FILETIME=[CD51DA40:01C3A448] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 11:31:48 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 05, 2003 9:22 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > > - Section 7.4.3: > > - In step 5 "The endpoint MAY attempt to send the=20 > message content again" > > Should we remove this text? If the message sending=20 > fails, so be it. > > The user can choose to send it again. This avoids the=20 > very large=20 > message > > being sent again (long messages have the potential to falsely=20 > timing out > > and the sender gets a 500 response). >=20 > I agree this should go. We may want to discuss possibility of=20 > establishing a replacement media session and then retrying=20 > the message=20 > there. In that case I think we perhaps should make it permissible for=20 > the retry to use the same TR-ID. It is then optional whether the=20 > recipient detects the duplicate or not. If I understand you correctly, you are suggesting that if a message = fails with a 500 or a timeout, then we create a new session and try = resending it there? If so, then I think I disagree. I think there should = not be any retransmission at all. The end user can choose to send the = message again, after he learns that the message did not really get = there. Also, you really want to tie TR-IDs across sessions? Regards, Hisham >=20 > This addresses the case where a relay crashes in an ungraceful way. >=20 > > - Open issue: NO. >=20 > I guess what I am proposing is YES, but with a weak mechanism=20 > - neither=20 > side is *required* to enable duplicate suppression, but the=20 > mechanism is=20 > there if both sides choose to use it. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 09:31:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10422; Thu, 6 Nov 2003 09:31:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlAK-0001qm-00; Thu, 06 Nov 2003 09:31:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHlAJ-0001qh-00; Thu, 06 Nov 2003 09:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlA6-0001aE-Tk; Thu, 06 Nov 2003 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlA5-0001Zi-0A for simple@optimus.ietf.org; Thu, 06 Nov 2003 09:31:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10396 for ; Thu, 6 Nov 2003 09:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlA3-0001qH-00 for simple@ietf.org; Thu, 06 Nov 2003 09:30:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHlA2-0001q0-00 for simple@ietf.org; Thu, 06 Nov 2003 09:30:58 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2003 06:35:15 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA6EUPw5028910; Thu, 6 Nov 2003 06:30:26 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT83179; Thu, 6 Nov 2003 09:30:24 -0500 (EST) Message-ID: <3FAA5AFF.1020308@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB70179738B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 09:30:23 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>I agree this should go. We may want to discuss possibility of >>establishing a replacement media session and then retrying >>the message >>there. In that case I think we perhaps should make it permissible for >>the retry to use the same TR-ID. It is then optional whether the >>recipient detects the duplicate or not. > > > If I understand you correctly, you are suggesting that if a message > fails with a 500 or a timeout, then we create a new session and try > resending it there? Yes, depending on the definition of "we". :-) I am suggesting that an IM *application* that wants to provide the best possible user experience might do this. > If so, then I think I disagree. I think there > should not be any retransmission at all. The end user can choose to > send the message again, after he learns that the message did not > really get there. If your application doesn't support the retransmission then of course you can choose to do that. I'm not suggesting that this be mandatory. > Also, you really want to tie TR-IDs across sessions? If the application chooses to use them that way. The main significant point here would be that *if* a TR-ID is reused on a "related" session then a recipient would be permitted to ignore the message. To avoid any confusion, it would probably be best to define an error response that indicates the message was recognized as a duplicate. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 09:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10442 for ; Thu, 6 Nov 2003 09:31:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlAM-0001az-CT for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 09:31:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6EVI0O006132 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 09:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlAM-0001ap-91 for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 09:31:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10422; Thu, 6 Nov 2003 09:31:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlAK-0001qm-00; Thu, 06 Nov 2003 09:31:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHlAJ-0001qh-00; Thu, 06 Nov 2003 09:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlA6-0001aE-Tk; Thu, 06 Nov 2003 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlA5-0001Zi-0A for simple@optimus.ietf.org; Thu, 06 Nov 2003 09:31:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10396 for ; Thu, 6 Nov 2003 09:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlA3-0001qH-00 for simple@ietf.org; Thu, 06 Nov 2003 09:30:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHlA2-0001q0-00 for simple@ietf.org; Thu, 06 Nov 2003 09:30:58 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2003 06:35:15 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA6EUPw5028910; Thu, 6 Nov 2003 06:30:26 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT83179; Thu, 6 Nov 2003 09:30:24 -0500 (EST) Message-ID: <3FAA5AFF.1020308@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB70179738B@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 09:30:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>I agree this should go. We may want to discuss possibility of >>establishing a replacement media session and then retrying >>the message >>there. In that case I think we perhaps should make it permissible for >>the retry to use the same TR-ID. It is then optional whether the >>recipient detects the duplicate or not. > > > If I understand you correctly, you are suggesting that if a message > fails with a 500 or a timeout, then we create a new session and try > resending it there? Yes, depending on the definition of "we". :-) I am suggesting that an IM *application* that wants to provide the best possible user experience might do this. > If so, then I think I disagree. I think there > should not be any retransmission at all. The end user can choose to > send the message again, after he learns that the message did not > really get there. If your application doesn't support the retransmission then of course you can choose to do that. I'm not suggesting that this be mandatory. > Also, you really want to tie TR-IDs across sessions? If the application chooses to use them that way. The main significant point here would be that *if* a TR-ID is reused on a "related" session then a recipient would be permitted to ignore the message. To avoid any confusion, it would probably be best to define an error response that indicates the message was recognized as a duplicate. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 14:18:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23882; Thu, 6 Nov 2003 14:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpes-0006Cl-00; Thu, 06 Nov 2003 14:19:06 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHper-0006CB-00; Thu, 06 Nov 2003 14:19:05 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHpVC-0008SF-B0; Thu, 06 Nov 2003 14:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpV6-0002dC-UW; Thu, 06 Nov 2003 14:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpU8-0002Xv-O1 for simple@optimus.ietf.org; Thu, 06 Nov 2003 14:08:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23455; Thu, 6 Nov 2003 14:07:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpU5-000639-00; Thu, 06 Nov 2003 14:07:57 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AHpU3-00061v-00; Thu, 06 Nov 2003 14:07:56 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA6J75ca013104; Thu, 6 Nov 2003 14:07:06 -0500 (EST) Message-ID: <3FAA9BD7.9070709@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 14:07:03 -0500 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi jonathan, > > could you describe how the domain authorization procedure works? > where do you get the domain part for the identifier. the problem we > saw in the past was that you have to understand the structure of > the identifier in order for it to work. I'm not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: dynamicsoft.com joe@dynamicsoft.com bob@dynamicsoft.com Where is the complexity here? > > ciao hannes > > btw, another small issue. the name of the authorization draft is > very misleading. there is no need to contain the name xcap in there > since the policies should actually be independent of xcap. i > noticed the problem with the names in various discussions. people > automatically think that those two belong together. Yes, I realize that - others have commented similarly. I will be happy to split it up into pieces, wth the XML schema separately, once we have a better grasp of how to bring these two works together. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 14:19:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23982 for ; Thu, 6 Nov 2003 14:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpew-0003FN-5k for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 14:19:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6JJAAI012477 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 14:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpew-0003FA-2f for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 14:19:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23882; Thu, 6 Nov 2003 14:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpes-0006Cl-00; Thu, 06 Nov 2003 14:19:06 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AHper-0006CB-00; Thu, 06 Nov 2003 14:19:05 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AHpVC-0008SF-B0; Thu, 06 Nov 2003 14:09:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpV6-0002dC-UW; Thu, 06 Nov 2003 14:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpU8-0002Xv-O1 for simple@optimus.ietf.org; Thu, 06 Nov 2003 14:08:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23455; Thu, 6 Nov 2003 14:07:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpU5-000639-00; Thu, 06 Nov 2003 14:07:57 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AHpU3-00061v-00; Thu, 06 Nov 2003 14:07:56 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA6J75ca013104; Thu, 6 Nov 2003 14:07:06 -0500 (EST) Message-ID: <3FAA9BD7.9070709@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 14:07:03 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > hi jonathan, > > could you describe how the domain authorization procedure works? > where do you get the domain part for the identifier. the problem we > saw in the past was that you have to understand the structure of > the identifier in order for it to work. I'm not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: dynamicsoft.com joe@dynamicsoft.com bob@dynamicsoft.com Where is the complexity here? > > ciao hannes > > btw, another small issue. the name of the authorization draft is > very misleading. there is no need to contain the name xcap in there > since the policies should actually be independent of xcap. i > noticed the problem with the names in various discussions. people > automatically think that those two belong together. Yes, I realize that - others have commented similarly. I will be happy to split it up into pieces, wth the XML schema separately, once we have a better grasp of how to bring these two works together. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 17:20:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04858; Thu, 6 Nov 2003 17:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsUy-0001t6-00; Thu, 06 Nov 2003 17:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsUy-0001t3-00; Thu, 06 Nov 2003 17:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsUx-00013a-E9; Thu, 06 Nov 2003 17:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsUJ-0000sY-7s for simple@optimus.ietf.org; Thu, 06 Nov 2003 17:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04724 for ; Thu, 6 Nov 2003 17:20:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsUG-0001rs-00 for simple@ietf.org; Thu, 06 Nov 2003 17:20:20 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHsUG-0001r1-00 for simple@ietf.org; Thu, 06 Nov 2003 17:20:20 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA6MJlmU013882; Thu, 6 Nov 2003 14:19:47 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADU33981; Thu, 6 Nov 2003 17:19:46 -0500 (EST) Message-ID: <3FAAC902.60507@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02- ending a session References: <2038BCC78B1AD641891A0D1AE133DBB70179738A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 17:19:46 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>I think the key is that in a graceful shutdown, a response >>must be sent >>for every message that is processed by the receiving end. Once having >>sent or received signaling initiating the shutdown of the >>session it may >>stop processing messages. Then, for the messages not >>processed, it may >>either send an error response of some sort, or else send no response. >> >>For this to be beneficial, both ends need to drain the connection, >>processing responses, as long as they have any unacknowledged >>messages >>outstanding. >> >>Message delivery failure will be minimized if both sides continue >>processing incoming messages, and sending responses to them, until an >>eof is received on the connection. This is even after the >>signaling is >>all completed. > > > This might work, but you have to make the restriction that an endpoint MUST NOT initiate any further SEND requests once it has sent or received a message session termination request (a SIP BYE for example). Yes, of course. > > Also, and endpoint MUST NOT terminate a message session if it is still receiving a large message. It MUST first send a 500 to that message indicating to the relay or the peer endpoint that it does not wish to continue receiving this large message. It can then terminate the session. To be a graceful close, yes. Nothing terrible happens if it doesn't do this, but perhaps more of that large message than necessary will be transmitted. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 17:21:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04884 for ; Thu, 6 Nov 2003 17:21:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsV2-00015m-4Q for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 17:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6ML8Dl004194 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 17:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsV2-00015Z-1Y for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04858; Thu, 6 Nov 2003 17:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsUy-0001t6-00; Thu, 06 Nov 2003 17:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsUy-0001t3-00; Thu, 06 Nov 2003 17:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsUx-00013a-E9; Thu, 06 Nov 2003 17:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsUJ-0000sY-7s for simple@optimus.ietf.org; Thu, 06 Nov 2003 17:20:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04724 for ; Thu, 6 Nov 2003 17:20:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsUG-0001rs-00 for simple@ietf.org; Thu, 06 Nov 2003 17:20:20 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHsUG-0001r1-00 for simple@ietf.org; Thu, 06 Nov 2003 17:20:20 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA6MJlmU013882; Thu, 6 Nov 2003 14:19:47 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADU33981; Thu, 6 Nov 2003 17:19:46 -0500 (EST) Message-ID: <3FAAC902.60507@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02- ending a session References: <2038BCC78B1AD641891A0D1AE133DBB70179738A@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 17:19:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>I think the key is that in a graceful shutdown, a response >>must be sent >>for every message that is processed by the receiving end. Once having >>sent or received signaling initiating the shutdown of the >>session it may >>stop processing messages. Then, for the messages not >>processed, it may >>either send an error response of some sort, or else send no response. >> >>For this to be beneficial, both ends need to drain the connection, >>processing responses, as long as they have any unacknowledged >>messages >>outstanding. >> >>Message delivery failure will be minimized if both sides continue >>processing incoming messages, and sending responses to them, until an >>eof is received on the connection. This is even after the >>signaling is >>all completed. > > > This might work, but you have to make the restriction that an endpoint MUST NOT initiate any further SEND requests once it has sent or received a message session termination request (a SIP BYE for example). Yes, of course. > > Also, and endpoint MUST NOT terminate a message session if it is still receiving a large message. It MUST first send a 500 to that message indicating to the relay or the peer endpoint that it does not wish to continue receiving this large message. It can then terminate the session. To be a graceful close, yes. Nothing terrible happens if it doesn't do this, but perhaps more of that large message than necessary will be transmitted. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 17:43:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05809; Thu, 6 Nov 2003 17:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsrI-0002GQ-00; Thu, 06 Nov 2003 17:44:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsrH-0002GB-00; Thu, 06 Nov 2003 17:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrC-0002b1-Jv; Thu, 06 Nov 2003 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsr1-0002aM-1h for simple@optimus.ietf.org; Thu, 06 Nov 2003 17:43:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05791; Thu, 6 Nov 2003 17:43:37 -0500 (EST) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqy-0002G3-00; Thu, 06 Nov 2003 17:43:48 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqx-0002G0-00; Thu, 06 Nov 2003 17:43:47 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA6MhUVY018401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2003 14:43:31 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA6MhSU0016667; Thu, 6 Nov 2003 14:43:28 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3FAA9BD7.9070709@dynamicsoft.com> References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> To: Jonathan Rosenberg , Tschofenig Hannes Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth Cc: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 14:43:28 -0800 At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > > > dynamicsoft.com > > joe@dynamicsoft.com > bob@dynamicsoft.com > > > >Where is the complexity here? The complexity here from the GeoPriv side is really in how additive permissions are meant to work. In order to ensure that the privacy policy is always within the user's tolerance, the theory has been to have a very small set of "grants" that are then always modified by addition. If the URI at which a specific addition is made is not available (or the object in which it is contained is not decryptable), then the results may be less than optimal, but there are no untoward privacy consequences, as there can never be a "grant statement" that takes something away. We talked about "except" in particular at the interim meeting and, from my memory, we had good agreement that "except" was powerful, interesting, but conflicted enough with the core theory and the needed functionality that it wouldn't be a phase one. Could I suggest that we consider splitting into two, one of which has except and one does not? We could have and . The first would be the basic grant: example.com where the second would allow: example.com joe@example.com. I think that would enable us to overlap a lot of the xcap language between SIMPLE and GEOPRIV, but allow GeoPriv to punt implementation of until a later time when it has worked out more of the surrounding infrastructure. It is inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and this looks like the most direct way to hack past the problem without losing the basic overlap. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 17:44:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05865 for ; Thu, 6 Nov 2003 17:44:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrM-0002hq-9I for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 17:44:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MiCFY010396 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 17:44:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrM-0002hb-5Y for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 17:44:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05809; Thu, 6 Nov 2003 17:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsrI-0002GQ-00; Thu, 06 Nov 2003 17:44:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHsrH-0002GB-00; Thu, 06 Nov 2003 17:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsrC-0002b1-Jv; Thu, 06 Nov 2003 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsr1-0002aM-1h for simple@optimus.ietf.org; Thu, 06 Nov 2003 17:43:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05791; Thu, 6 Nov 2003 17:43:37 -0500 (EST) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqy-0002G3-00; Thu, 06 Nov 2003 17:43:48 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AHsqx-0002G0-00; Thu, 06 Nov 2003 17:43:47 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA6MhUVY018401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2003 14:43:31 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA6MhSU0016667; Thu, 6 Nov 2003 14:43:28 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3FAA9BD7.9070709@dynamicsoft.com> References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> To: Jonathan Rosenberg , Tschofenig Hannes Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth Cc: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 6 Nov 2003 14:43:28 -0800 At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > > > dynamicsoft.com > > joe@dynamicsoft.com > bob@dynamicsoft.com > > > >Where is the complexity here? The complexity here from the GeoPriv side is really in how additive permissions are meant to work. In order to ensure that the privacy policy is always within the user's tolerance, the theory has been to have a very small set of "grants" that are then always modified by addition. If the URI at which a specific addition is made is not available (or the object in which it is contained is not decryptable), then the results may be less than optimal, but there are no untoward privacy consequences, as there can never be a "grant statement" that takes something away. We talked about "except" in particular at the interim meeting and, from my memory, we had good agreement that "except" was powerful, interesting, but conflicted enough with the core theory and the needed functionality that it wouldn't be a phase one. Could I suggest that we consider splitting into two, one of which has except and one does not? We could have and . The first would be the basic grant: example.com where the second would allow: example.com joe@example.com. I think that would enable us to overlap a lot of the xcap language between SIMPLE and GEOPRIV, but allow GeoPriv to punt implementation of until a later time when it has worked out more of the surrounding infrastructure. It is inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and this looks like the most direct way to hack past the problem without losing the basic overlap. regards, Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 6 20:29:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11642; Thu, 6 Nov 2003 20:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvRw-0004AK-00; Thu, 06 Nov 2003 20:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHvRv-0004AH-00; Thu, 06 Nov 2003 20:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvRp-0003Jj-H9; Thu, 06 Nov 2003 20:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvQy-0003Ii-C2 for simple@optimus.ietf.org; Thu, 06 Nov 2003 20:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11612; Thu, 6 Nov 2003 20:28:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvQw-00049Z-00; Thu, 06 Nov 2003 20:29:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AHvQv-00048X-00; Thu, 06 Nov 2003 20:29:05 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA71SRhL006258; Thu, 6 Nov 2003 20:28:27 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA71SPg05894; Thu, 6 Nov 2003 20:28:26 -0500 Message-ID: <3FAAF539.2090803@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Jonathan Rosenberg , Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 20:28:25 -0500 Content-Transfer-Encoding: 7bit If there is consensus that we really can't avoid exceptions, I would suggest a variation of Ted's approach, namely to have a clear, separate exceptions list: - First, consult the exceptions list. If there's a match in the exceptions list, there is no need to consult the second list. If the LS or PA can't access the exceptions list, the system delivers no information and fails hard for that delivery destination. The exception list permits no inclusions, no all-within-domain wildcards and no external references. (Permissions within the exceptions list are still additive.) - If no match, consult the normal additive-privileges list, with no exceptions. This supports the all-20,000-Columbia-employees except Alice and Bob, but does not support Columbia-except-the-EE-department. This has the advantage that the row-model is maintained, rather than having lists of exceptions attached to each rule. GEOPRIV might then decide not to support the exception list type, but the regular list type would be compatible. Blacklists were popular for spam-protection early on, but I think everyone has realized by now that they are close to useless. I'd hate to create a complicated, brittle, difficult-to-predict system just to find out a year later that this expensive feature turned out to be mostly an empty promise, in terms of increasing user privacy. Note that I'm not advocating the solution - I'd rather not add the complexity and I'm not sure whether I have caught all the possible failure cases. It would be helpful if others would speak up, as this is an important issue to settle, soon. hardie@qualcomm.com wrote: > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: >> >> >> dynamicsoft.com >> >> joe@dynamicsoft.com >> bob@dynamicsoft.com >> >> >> >>Where is the complexity here? > > > > The complexity here from the GeoPriv side is really in how additive permissions are > meant to work. In order to ensure that the privacy policy is always within the > user's tolerance, the theory has been to have a very small set of "grants" that > are then always modified by addition. If the URI at which a specific addition > is made is not available (or the object in which it is contained is not decryptable), > then the results may be less than optimal, but there are no untoward > privacy consequences, as there can never be a "grant statement" that takes > something away. We talked about "except" in particular at the interim meeting > and, from my memory, we had good agreement that "except" was powerful, > interesting, but conflicted enough with the core theory and the needed functionality > that it wouldn't be a phase one. > > Could I suggest that we consider splitting into two, one of which > has except and one does not? We could have and . > The first would be the basic grant: > > example.com > > where the second would allow: > > example.com > joe@example.com. > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > GEOPRIV, but allow GeoPriv to punt implementation of until > a later time when it has worked out more of the surrounding infrastructure. It is > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > this looks like the most direct way to hack past the problem without losing > the basic overlap. > regards, > Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 6 20:30:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11697 for ; Thu, 6 Nov 2003 20:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvRz-0003Lu-Jp for simple-archive@odin.ietf.org; Thu, 06 Nov 2003 20:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA71UB3I012885 for simple-archive@odin.ietf.org; Thu, 6 Nov 2003 20:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvRz-0003Lk-Ge for simple-web-archive@optimus.ietf.org; Thu, 06 Nov 2003 20:30:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11642; Thu, 6 Nov 2003 20:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvRw-0004AK-00; Thu, 06 Nov 2003 20:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AHvRv-0004AH-00; Thu, 06 Nov 2003 20:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvRp-0003Jj-H9; Thu, 06 Nov 2003 20:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHvQy-0003Ii-C2 for simple@optimus.ietf.org; Thu, 06 Nov 2003 20:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11612; Thu, 6 Nov 2003 20:28:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHvQw-00049Z-00; Thu, 06 Nov 2003 20:29:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AHvQv-00048X-00; Thu, 06 Nov 2003 20:29:05 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA71SRhL006258; Thu, 6 Nov 2003 20:28:27 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA71SPg05894; Thu, 6 Nov 2003 20:28:26 -0500 Message-ID: <3FAAF539.2090803@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Jonathan Rosenberg , Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 06 Nov 2003 20:28:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If there is consensus that we really can't avoid exceptions, I would suggest a variation of Ted's approach, namely to have a clear, separate exceptions list: - First, consult the exceptions list. If there's a match in the exceptions list, there is no need to consult the second list. If the LS or PA can't access the exceptions list, the system delivers no information and fails hard for that delivery destination. The exception list permits no inclusions, no all-within-domain wildcards and no external references. (Permissions within the exceptions list are still additive.) - If no match, consult the normal additive-privileges list, with no exceptions. This supports the all-20,000-Columbia-employees except Alice and Bob, but does not support Columbia-except-the-EE-department. This has the advantage that the row-model is maintained, rather than having lists of exceptions attached to each rule. GEOPRIV might then decide not to support the exception list type, but the regular list type would be compatible. Blacklists were popular for spam-protection early on, but I think everyone has realized by now that they are close to useless. I'd hate to create a complicated, brittle, difficult-to-predict system just to find out a year later that this expensive feature turned out to be mostly an empty promise, in terms of increasing user privacy. Note that I'm not advocating the solution - I'd rather not add the complexity and I'm not sure whether I have caught all the possible failure cases. It would be helpful if others would speak up, as this is an important issue to settle, soon. hardie@qualcomm.com wrote: > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: >> >> >> dynamicsoft.com >> >> joe@dynamicsoft.com >> bob@dynamicsoft.com >> >> >> >>Where is the complexity here? > > > > The complexity here from the GeoPriv side is really in how additive permissions are > meant to work. In order to ensure that the privacy policy is always within the > user's tolerance, the theory has been to have a very small set of "grants" that > are then always modified by addition. If the URI at which a specific addition > is made is not available (or the object in which it is contained is not decryptable), > then the results may be less than optimal, but there are no untoward > privacy consequences, as there can never be a "grant statement" that takes > something away. We talked about "except" in particular at the interim meeting > and, from my memory, we had good agreement that "except" was powerful, > interesting, but conflicted enough with the core theory and the needed functionality > that it wouldn't be a phase one. > > Could I suggest that we consider splitting into two, one of which > has except and one does not? We could have and . > The first would be the basic grant: > > example.com > > where the second would allow: > > example.com > joe@example.com. > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > GEOPRIV, but allow GeoPriv to punt implementation of until > a later time when it has worked out more of the surrounding infrastructure. It is > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > this looks like the most direct way to hack past the problem without losing > the basic overlap. > regards, > Ted Hardie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 02:38:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03525; Fri, 7 Nov 2003 02:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1CA-0000UC-00; Fri, 07 Nov 2003 02:38:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1C9-0000U8-00; Fri, 07 Nov 2003 02:38:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1C2-0003dP-D4; Fri, 07 Nov 2003 02:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Bp-0003ai-7G for simple@optimus.ietf.org; Fri, 07 Nov 2003 02:37:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03498; Fri, 7 Nov 2003 02:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Bl-0000TN-00; Fri, 07 Nov 2003 02:37:49 -0500 Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Bk-0000TK-00; Fri, 07 Nov 2003 02:37:48 -0500 Received: from mailgate3.nec.co.jp ([10.7.69.162]) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id hA77bkl00774; Fri, 7 Nov 2003 16:37:46 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id hA77bjv26576; Fri, 7 Nov 2003 16:37:45 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id hA77bi212256; Fri, 7 Nov 2003 16:37:44 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.7/8.11.7) with ESMTP id hA77biJ19793; Fri, 7 Nov 2003 16:37:44 +0900 (JST) Received: from splpe19 (d-lab5-03.lab5.netlab.nec.co.jp [10.17.226.82]) by dns03.netlab.nec.co.jp (8.11.7/8.11.7) with SMTP id hA77bhT09925; Fri, 7 Nov 2003 16:37:43 +0900 (JST) Message-ID: <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> From: "Naoko ITO" To: "Simple WG" Cc: References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 16:37:43 +0900 Content-Transfer-Encoding: 7bit Hello, I think a separate excepton list is very useful, corresponding to the exact concept of 'black list.' Still, I'd like to have an except clause in a permission statment as well, which can be used for a differenct purpose, i.e., giving different permissions to some groups of the watchers. I don't understand why the except clause in each permission statement should be dismissed while the separate exception list model can be supported. 1) introducing a separate exception list but not supporting it, 2) introducing an except clause in each permission but not supporting it. In the case of Option #1, the rule enforcer should drop all the permission statements in the rule set in order to prevent those should-be-excepted watchers from accidentally obtaining information, if there is an exception statement which cannot be understood. i.e., no permission is granted to anybody at all. In the case of Option #2, the rule enforcer should drop the permission statements with unknown except clauses, which still allows some watchers to obtain information. It seems to me that both options give us the ways to ensure the privacy-safe even if the rule enforcer does not support the except mechanism, and rather the latter is more elastic or fault-tolerant. Or is this just plausible? As for maintaining the row-model, I don't think the former model maintains the row-model, while the entire rule set has no meaning if the actual rule set once has an exception statement. If it means not supporting the exception at all, the same thing can be done with the except clause in each permission. I see no reason to dismiss the latter approach and would suggest to keep both. Regards, ----- Naoko Ito / NEC ----- Original Message ----- From: "Henning Schulzrinne" To: Cc: "Jonathan Rosenberg" ; "Tschofenig Hannes" ; "'Rosen, Brian'" ; "Simple WG" ; Sent: Friday, November 07, 2003 10:28 AM Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > If there is consensus that we really can't avoid exceptions, I would > suggest a variation of Ted's approach, namely to have a clear, separate > exceptions list: > > - First, consult the exceptions list. If there's a match in the > exceptions list, there is no need to consult the second list. If the LS > or PA can't access the exceptions list, the system delivers no > information and fails hard for that delivery destination. The exception > list permits no inclusions, no all-within-domain wildcards and no > external references. (Permissions within the exceptions list are still > additive.) > > - If no match, consult the normal additive-privileges list, with no > exceptions. > > This supports the all-20,000-Columbia-employees except Alice and Bob, > but does not support Columbia-except-the-EE-department. > > This has the advantage that the row-model is maintained, rather than > having lists of exceptions attached to each rule. > > GEOPRIV might then decide not to support the exception list type, but > the regular list type would be compatible. > > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd hate to > create a complicated, brittle, difficult-to-predict system just to find > out a year later that this expensive feature turned out to be mostly an > empty promise, in terms of increasing user privacy. > > Note that I'm not advocating the solution - I'd rather not add the > complexity and I'm not sure whether I have caught all the possible > failure cases. > > It would be helpful if others would speak up, as this is an important > issue to settle, soon. > > hardie@qualcomm.com wrote: > > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > > > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > >> > >> > >> dynamicsoft.com > >> > >> joe@dynamicsoft.com > >> bob@dynamicsoft.com > >> > >> > >> > >>Where is the complexity here? > > > > > > > > The complexity here from the GeoPriv side is really in how additive permissions are > > meant to work. In order to ensure that the privacy policy is always within the > > user's tolerance, the theory has been to have a very small set of "grants" that > > are then always modified by addition. If the URI at which a specific addition > > is made is not available (or the object in which it is contained is not decryptable), > > then the results may be less than optimal, but there are no untoward > > privacy consequences, as there can never be a "grant statement" that takes > > something away. We talked about "except" in particular at the interim meeting > > and, from my memory, we had good agreement that "except" was powerful, > > interesting, but conflicted enough with the core theory and the needed functionality > > that it wouldn't be a phase one. > > > > Could I suggest that we consider splitting into two, one of which > > has except and one does not? We could have and . > > The first would be the basic grant: > > > > example.com > > > > where the second would allow: > > > > example.com > > joe@example.com. > > > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > > GEOPRIV, but allow GeoPriv to punt implementation of until > > a later time when it has worked out more of the surrounding infrastructure. It is > > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > > this looks like the most direct way to hack past the problem without losing > > the basic overlap. > > regards, > > Ted Hardie > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 7 02:38:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03603 for ; Fri, 7 Nov 2003 02:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1CI-0003m4-IU for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 02:38:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA77cLTM014491 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 02:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1CG-0003jN-Eb for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 02:38:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03525; Fri, 7 Nov 2003 02:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1CA-0000UC-00; Fri, 07 Nov 2003 02:38:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1C9-0000U8-00; Fri, 07 Nov 2003 02:38:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1C2-0003dP-D4; Fri, 07 Nov 2003 02:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Bp-0003ai-7G for simple@optimus.ietf.org; Fri, 07 Nov 2003 02:37:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03498; Fri, 7 Nov 2003 02:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Bl-0000TN-00; Fri, 07 Nov 2003 02:37:49 -0500 Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Bk-0000TK-00; Fri, 07 Nov 2003 02:37:48 -0500 Received: from mailgate3.nec.co.jp ([10.7.69.162]) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id hA77bkl00774; Fri, 7 Nov 2003 16:37:46 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id hA77bjv26576; Fri, 7 Nov 2003 16:37:45 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id hA77bi212256; Fri, 7 Nov 2003 16:37:44 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.7/8.11.7) with ESMTP id hA77biJ19793; Fri, 7 Nov 2003 16:37:44 +0900 (JST) Received: from splpe19 (d-lab5-03.lab5.netlab.nec.co.jp [10.17.226.82]) by dns03.netlab.nec.co.jp (8.11.7/8.11.7) with SMTP id hA77bhT09925; Fri, 7 Nov 2003 16:37:43 +0900 (JST) Message-ID: <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> From: "Naoko ITO" To: "Simple WG" Cc: References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 16:37:43 +0900 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I think a separate excepton list is very useful, corresponding to the exact concept of 'black list.' Still, I'd like to have an except clause in a permission statment as well, which can be used for a differenct purpose, i.e., giving different permissions to some groups of the watchers. I don't understand why the except clause in each permission statement should be dismissed while the separate exception list model can be supported. 1) introducing a separate exception list but not supporting it, 2) introducing an except clause in each permission but not supporting it. In the case of Option #1, the rule enforcer should drop all the permission statements in the rule set in order to prevent those should-be-excepted watchers from accidentally obtaining information, if there is an exception statement which cannot be understood. i.e., no permission is granted to anybody at all. In the case of Option #2, the rule enforcer should drop the permission statements with unknown except clauses, which still allows some watchers to obtain information. It seems to me that both options give us the ways to ensure the privacy-safe even if the rule enforcer does not support the except mechanism, and rather the latter is more elastic or fault-tolerant. Or is this just plausible? As for maintaining the row-model, I don't think the former model maintains the row-model, while the entire rule set has no meaning if the actual rule set once has an exception statement. If it means not supporting the exception at all, the same thing can be done with the except clause in each permission. I see no reason to dismiss the latter approach and would suggest to keep both. Regards, ----- Naoko Ito / NEC ----- Original Message ----- From: "Henning Schulzrinne" To: Cc: "Jonathan Rosenberg" ; "Tschofenig Hannes" ; "'Rosen, Brian'" ; "Simple WG" ; Sent: Friday, November 07, 2003 10:28 AM Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > If there is consensus that we really can't avoid exceptions, I would > suggest a variation of Ted's approach, namely to have a clear, separate > exceptions list: > > - First, consult the exceptions list. If there's a match in the > exceptions list, there is no need to consult the second list. If the LS > or PA can't access the exceptions list, the system delivers no > information and fails hard for that delivery destination. The exception > list permits no inclusions, no all-within-domain wildcards and no > external references. (Permissions within the exceptions list are still > additive.) > > - If no match, consult the normal additive-privileges list, with no > exceptions. > > This supports the all-20,000-Columbia-employees except Alice and Bob, > but does not support Columbia-except-the-EE-department. > > This has the advantage that the row-model is maintained, rather than > having lists of exceptions attached to each rule. > > GEOPRIV might then decide not to support the exception list type, but > the regular list type would be compatible. > > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd hate to > create a complicated, brittle, difficult-to-predict system just to find > out a year later that this expensive feature turned out to be mostly an > empty promise, in terms of increasing user privacy. > > Note that I'm not advocating the solution - I'd rather not add the > complexity and I'm not sure whether I have caught all the possible > failure cases. > > It would be helpful if others would speak up, as this is an important > issue to settle, soon. > > hardie@qualcomm.com wrote: > > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > > > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > >> > >> > >> dynamicsoft.com > >> > >> joe@dynamicsoft.com > >> bob@dynamicsoft.com > >> > >> > >> > >>Where is the complexity here? > > > > > > > > The complexity here from the GeoPriv side is really in how additive permissions are > > meant to work. In order to ensure that the privacy policy is always within the > > user's tolerance, the theory has been to have a very small set of "grants" that > > are then always modified by addition. If the URI at which a specific addition > > is made is not available (or the object in which it is contained is not decryptable), > > then the results may be less than optimal, but there are no untoward > > privacy consequences, as there can never be a "grant statement" that takes > > something away. We talked about "except" in particular at the interim meeting > > and, from my memory, we had good agreement that "except" was powerful, > > interesting, but conflicted enough with the core theory and the needed functionality > > that it wouldn't be a phase one. > > > > Could I suggest that we consider splitting into two, one of which > > has except and one does not? We could have and . > > The first would be the basic grant: > > > > example.com > > > > where the second would allow: > > > > example.com > > joe@example.com. > > > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > > GEOPRIV, but allow GeoPriv to punt implementation of until > > a later time when it has worked out more of the surrounding infrastructure. It is > > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > > this looks like the most direct way to hack past the problem without losing > > the basic overlap. > > regards, > > Ted Hardie > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 7 02:38:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03601 for ; Fri, 7 Nov 2003 02:38:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1CH-0003ll-Q7 for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 02:38:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA77cLML014343 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 02:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1CF-0003jE-OI for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 02:38:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03526; Fri, 7 Nov 2003 02:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1CA-0000UG-00; Fri, 07 Nov 2003 02:38:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1CA-0000U9-00; Fri, 07 Nov 2003 02:38:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Bz-0003cc-1G; Fri, 07 Nov 2003 02:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Be-0003Z1-4E for simple@optimus.ietf.org; Fri, 07 Nov 2003 02:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03490; Fri, 7 Nov 2003 02:37:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1BZ-0000Su-00; Fri, 07 Nov 2003 02:37:37 -0500 Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by ietf-mx with esmtp (Exim 4.12) id 1AI1BY-0000Sm-00; Fri, 07 Nov 2003 02:37:37 -0500 Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id hA77bYl00543; Fri, 7 Nov 2003 16:37:34 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id hA77bXs06738; Fri, 7 Nov 2003 16:37:33 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id hA77bX212009; Fri, 7 Nov 2003 16:37:33 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.7/8.11.7) with ESMTP id hA77bWJ19789; Fri, 7 Nov 2003 16:37:32 +0900 (JST) Received: from splpe19 (d-lab5-03.lab5.netlab.nec.co.jp [10.17.226.82]) by dns03.netlab.nec.co.jp (8.11.7/8.11.7) with SMTP id hA77bWT09920; Fri, 7 Nov 2003 16:37:32 +0900 (JST) Message-ID: <004401c3a502$00ff6100$52e2110a@lab5.netlab.nec.co.jp> From: "Naoko ITO" To: "Simple WG" Cc: References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 16:37:31 +0900 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I think the black list aproach still has advantages in some situations where I'm afraid the white list model may cause another privacy issue. In a situation like CUG services where the service providers give admittance to some privileged people, they may see benefits of accessing to/being accessed by unknown people except some malicious people. If there are no way to specify the policy like "anybody but those identified people," they need to list every member, who otherwise might not be identified/revealed by those people until some time later. I think the services should decide which model they support. Some services may disallow statements giving a permission to 'any' or a permission including an except clause. I would expect the specification itself should support both models. Regards, ----- Naoko Ito / NEC ----- Original Message ----- From: "Henning Schulzrinne" To: Cc: "Jonathan Rosenberg" ; "Tschofenig Hannes" ; "'Rosen, Brian'" ; "Simple WG" ; Sent: Friday, November 07, 2003 10:28 AM Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > If there is consensus that we really can't avoid exceptions, I would > suggest a variation of Ted's approach, namely to have a clear, separate > exceptions list: > > - First, consult the exceptions list. If there's a match in the > exceptions list, there is no need to consult the second list. If the LS > or PA can't access the exceptions list, the system delivers no > information and fails hard for that delivery destination. The exception > list permits no inclusions, no all-within-domain wildcards and no > external references. (Permissions within the exceptions list are still > additive.) > > - If no match, consult the normal additive-privileges list, with no > exceptions. > > This supports the all-20,000-Columbia-employees except Alice and Bob, > but does not support Columbia-except-the-EE-department. > > This has the advantage that the row-model is maintained, rather than > having lists of exceptions attached to each rule. > > GEOPRIV might then decide not to support the exception list type, but > the regular list type would be compatible. > > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd hate to > create a complicated, brittle, difficult-to-predict system just to find > out a year later that this expensive feature turned out to be mostly an > empty promise, in terms of increasing user privacy. > > Note that I'm not advocating the solution - I'd rather not add the > complexity and I'm not sure whether I have caught all the possible > failure cases. > > It would be helpful if others would speak up, as this is an important > issue to settle, soon. > > hardie@qualcomm.com wrote: > > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > > > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > >> > >> > >> dynamicsoft.com > >> > >> joe@dynamicsoft.com > >> bob@dynamicsoft.com > >> > >> > >> > >>Where is the complexity here? > > > > > > > > The complexity here from the GeoPriv side is really in how additive permissions are > > meant to work. In order to ensure that the privacy policy is always within the > > user's tolerance, the theory has been to have a very small set of "grants" that > > are then always modified by addition. If the URI at which a specific addition > > is made is not available (or the object in which it is contained is not decryptable), > > then the results may be less than optimal, but there are no untoward > > privacy consequences, as there can never be a "grant statement" that takes > > something away. We talked about "except" in particular at the interim meeting > > and, from my memory, we had good agreement that "except" was powerful, > > interesting, but conflicted enough with the core theory and the needed functionality > > that it wouldn't be a phase one. > > > > Could I suggest that we consider splitting into two, one of which > > has except and one does not? We could have and . > > The first would be the basic grant: > > > > example.com > > > > where the second would allow: > > > > example.com > > joe@example.com. > > > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > > GEOPRIV, but allow GeoPriv to punt implementation of until > > a later time when it has worked out more of the surrounding infrastructure. It is > > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > > this looks like the most direct way to hack past the problem without losing > > the basic overlap. > > regards, > > Ted Hardie > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 03:37:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03526; Fri, 7 Nov 2003 02:38:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1CA-0000UG-00; Fri, 07 Nov 2003 02:38:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI1CA-0000U9-00; Fri, 07 Nov 2003 02:38:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Bz-0003cc-1G; Fri, 07 Nov 2003 02:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Be-0003Z1-4E for simple@optimus.ietf.org; Fri, 07 Nov 2003 02:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03490; Fri, 7 Nov 2003 02:37:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1BZ-0000Su-00; Fri, 07 Nov 2003 02:37:37 -0500 Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by ietf-mx with esmtp (Exim 4.12) id 1AI1BY-0000Sm-00; Fri, 07 Nov 2003 02:37:37 -0500 Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id hA77bYl00543; Fri, 7 Nov 2003 16:37:34 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id hA77bXs06738; Fri, 7 Nov 2003 16:37:33 +0900 (JST) Received: from dns02.netlab.nec.co.jp (dns02.netlab.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id hA77bX212009; Fri, 7 Nov 2003 16:37:33 +0900 (JST) Received: from dns03.netlab.nec.co.jp (dns03.netlab.nec.co.jp [10.17.225.65]) by dns02.netlab.nec.co.jp (8.11.7/8.11.7) with ESMTP id hA77bWJ19789; Fri, 7 Nov 2003 16:37:32 +0900 (JST) Received: from splpe19 (d-lab5-03.lab5.netlab.nec.co.jp [10.17.226.82]) by dns03.netlab.nec.co.jp (8.11.7/8.11.7) with SMTP id hA77bWT09920; Fri, 7 Nov 2003 16:37:32 +0900 (JST) Message-ID: <004401c3a502$00ff6100$52e2110a@lab5.netlab.nec.co.jp> From: "Naoko ITO" To: "Simple WG" Cc: References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 16:37:31 +0900 Content-Transfer-Encoding: 7bit Hello, I think the black list aproach still has advantages in some situations where I'm afraid the white list model may cause another privacy issue. In a situation like CUG services where the service providers give admittance to some privileged people, they may see benefits of accessing to/being accessed by unknown people except some malicious people. If there are no way to specify the policy like "anybody but those identified people," they need to list every member, who otherwise might not be identified/revealed by those people until some time later. I think the services should decide which model they support. Some services may disallow statements giving a permission to 'any' or a permission including an except clause. I would expect the specification itself should support both models. Regards, ----- Naoko Ito / NEC ----- Original Message ----- From: "Henning Schulzrinne" To: Cc: "Jonathan Rosenberg" ; "Tschofenig Hannes" ; "'Rosen, Brian'" ; "Simple WG" ; Sent: Friday, November 07, 2003 10:28 AM Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > If there is consensus that we really can't avoid exceptions, I would > suggest a variation of Ted's approach, namely to have a clear, separate > exceptions list: > > - First, consult the exceptions list. If there's a match in the > exceptions list, there is no need to consult the second list. If the LS > or PA can't access the exceptions list, the system delivers no > information and fails hard for that delivery destination. The exception > list permits no inclusions, no all-within-domain wildcards and no > external references. (Permissions within the exceptions list are still > additive.) > > - If no match, consult the normal additive-privileges list, with no > exceptions. > > This supports the all-20,000-Columbia-employees except Alice and Bob, > but does not support Columbia-except-the-EE-department. > > This has the advantage that the row-model is maintained, rather than > having lists of exceptions attached to each rule. > > GEOPRIV might then decide not to support the exception list type, but > the regular list type would be compatible. > > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd hate to > create a complicated, brittle, difficult-to-predict system just to find > out a year later that this expensive feature turned out to be mostly an > empty promise, in terms of increasing user privacy. > > Note that I'm not advocating the solution - I'd rather not add the > complexity and I'm not sure whether I have caught all the possible > failure cases. > > It would be helpful if others would speak up, as this is an important > issue to settle, soon. > > hardie@qualcomm.com wrote: > > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > > > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > >> > >> > >> dynamicsoft.com > >> > >> joe@dynamicsoft.com > >> bob@dynamicsoft.com > >> > >> > >> > >>Where is the complexity here? > > > > > > > > The complexity here from the GeoPriv side is really in how additive permissions are > > meant to work. In order to ensure that the privacy policy is always within the > > user's tolerance, the theory has been to have a very small set of "grants" that > > are then always modified by addition. If the URI at which a specific addition > > is made is not available (or the object in which it is contained is not decryptable), > > then the results may be less than optimal, but there are no untoward > > privacy consequences, as there can never be a "grant statement" that takes > > something away. We talked about "except" in particular at the interim meeting > > and, from my memory, we had good agreement that "except" was powerful, > > interesting, but conflicted enough with the core theory and the needed functionality > > that it wouldn't be a phase one. > > > > Could I suggest that we consider splitting into two, one of which > > has except and one does not? We could have and . > > The first would be the basic grant: > > > > example.com > > > > where the second would allow: > > > > example.com > > joe@example.com. > > > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > > GEOPRIV, but allow GeoPriv to punt implementation of until > > a later time when it has worked out more of the surrounding infrastructure. It is > > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > > this looks like the most direct way to hack past the problem without losing > > the basic overlap. > > regards, > > Ted Hardie > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 04:52:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08110; Fri, 7 Nov 2003 04:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Id-0002FV-00; Fri, 07 Nov 2003 04:53:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3Id-0002FS-00; Fri, 07 Nov 2003 04:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Ib-0004TK-Dp; Fri, 07 Nov 2003 04:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3IX-0004Sz-M1 for simple@optimus.ietf.org; Fri, 07 Nov 2003 04:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08101; Fri, 7 Nov 2003 04:52:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3IU-0002FG-00; Fri, 07 Nov 2003 04:52:54 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AI3IT-0002FC-00; Fri, 07 Nov 2003 04:52:53 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hA79qrJ13241; Fri, 7 Nov 2003 10:52:53 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA79qqs19685; Fri, 7 Nov 2003 10:52:52 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 10:52:34 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0406@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" Cc: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:52:34 +0100 hi jonathan, the problem with your approach is the following: you are simply assuming an email type of identity (which is taken from the authentication procedure). there you can simply split the domain part from the user part. however, geopriv tries to support different 'using protocols'. one possible using protocol is sip but there are many others. these using protocols typically have different authentication mechanisms which again use different identities. identities in http digest, x.509 certificates, kerberos principal names etc. have a different structure. you need to know the structure in order to extract the domain part. without your approach you don't need to understand the structure of the identifier. you only do an equality match. ciao hannes > > hi jonathan, > > > > could you describe how the domain authorization procedure works? > > where do you get the domain part for the identifier. the problem we > > saw in the past was that you have to understand the structure of > > the identifier in order for it to work. > > I'm not sure I follow. I work for dynamicsoft.com. All URIs in my > domain are user@dynamicsoft.com. I'd like a policy which > allows anyone > in dynamicsoft.com, but blocks a few irritating people, say joe and > bob. So, I would have a policy like this: > > > dynamicsoft.com > > joe@dynamicsoft.com > bob@dynamicsoft.com > > > > > Where is the complexity here? > > > > > > ciao hannes > > > > btw, another small issue. the name of the authorization draft is > > very misleading. there is no need to contain the name xcap in there > > since the policies should actually be independent of xcap. i > > noticed the problem with the names in various discussions. people > > automatically think that those two belong together. > > Yes, I realize that - others have commented similarly. I will > be happy > to split it up into pieces, wth the XML schema separately, once we > have a better grasp of how to bring these two works together. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 04:53:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08150 for ; Fri, 7 Nov 2003 04:53:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Ii-0004WY-Hb for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 04:53:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79r8HE017389 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 04:53:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Ii-0004WO-84 for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 04:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08110; Fri, 7 Nov 2003 04:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3Id-0002FV-00; Fri, 07 Nov 2003 04:53:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3Id-0002FS-00; Fri, 07 Nov 2003 04:53:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3Ib-0004TK-Dp; Fri, 07 Nov 2003 04:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3IX-0004Sz-M1 for simple@optimus.ietf.org; Fri, 07 Nov 2003 04:52:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08101; Fri, 7 Nov 2003 04:52:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3IU-0002FG-00; Fri, 07 Nov 2003 04:52:54 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AI3IT-0002FC-00; Fri, 07 Nov 2003 04:52:53 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hA79qrJ13241; Fri, 7 Nov 2003 10:52:53 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hA79qqs19685; Fri, 7 Nov 2003 10:52:52 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Fri, 7 Nov 2003 10:52:34 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0406@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" Cc: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:52:34 +0100 hi jonathan, the problem with your approach is the following: you are simply assuming an email type of identity (which is taken from the authentication procedure). there you can simply split the domain part from the user part. however, geopriv tries to support different 'using protocols'. one possible using protocol is sip but there are many others. these using protocols typically have different authentication mechanisms which again use different identities. identities in http digest, x.509 certificates, kerberos principal names etc. have a different structure. you need to know the structure in order to extract the domain part. without your approach you don't need to understand the structure of the identifier. you only do an equality match. ciao hannes > > hi jonathan, > > > > could you describe how the domain authorization procedure works? > > where do you get the domain part for the identifier. the problem we > > saw in the past was that you have to understand the structure of > > the identifier in order for it to work. > > I'm not sure I follow. I work for dynamicsoft.com. All URIs in my > domain are user@dynamicsoft.com. I'd like a policy which > allows anyone > in dynamicsoft.com, but blocks a few irritating people, say joe and > bob. So, I would have a policy like this: > > > dynamicsoft.com > > joe@dynamicsoft.com > bob@dynamicsoft.com > > > > > Where is the complexity here? > > > > > > ciao hannes > > > > btw, another small issue. the name of the authorization draft is > > very misleading. there is no need to contain the name xcap in there > > since the policies should actually be independent of xcap. i > > noticed the problem with the names in various discussions. people > > automatically think that those two belong together. > > Yes, I realize that - others have commented similarly. I will > be happy > to split it up into pieces, wth the XML schema separately, once we > have a better grasp of how to bring these two works together. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 05:12:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08718; Fri, 7 Nov 2003 05:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3bx-0002Sk-00; Fri, 07 Nov 2003 05:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3bx-0002Sg-00; Fri, 07 Nov 2003 05:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3bx-0005oN-LW; Fri, 07 Nov 2003 05:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3bu-0005oC-8I for simple@optimus.ietf.org; Fri, 07 Nov 2003 05:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08713 for ; Fri, 7 Nov 2003 05:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3bq-0002Sd-00 for simple@ietf.org; Fri, 07 Nov 2003 05:12:54 -0500 Received: from smtp2.clb.oleane.net ([213.56.31.18]) by ietf-mx with esmtp (Exim 4.12) id 1AI3bq-0002SU-00 for simple@ietf.org; Fri, 07 Nov 2003 05:12:54 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.clb.oleane.net with SMTP id hA7ACOfo030422 for ; Fri, 7 Nov 2003 11:12:24 +0100 Message-ID: <042901c3a518$294e47a0$0601a8c0@www.oleane.com> From: "M Winkhler" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01C3A520.8A959060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Simple] WiMAX Summit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 11:16:07 +0100 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0426_01C3A520.8A959060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are WiMAX and WiFi complementary (local vs. metropolitan area = networking)?=20 When and how will WiMAX evolve towards mobility?=20 Can WiMAX be considered as a migration path to 4G?=20 How is addressed the interoperability challenge?=20 These questions, among others, will be addressed during the WiMAX = Summit, to be held in Paris on May 25 to 28, 2004.=20 A call for papers has been launched on-line at: http://www.upperside.fr/wimax04/wimax04intro.htm ------=_NextPart_000_0426_01C3A520.8A959060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0426_01C3A520.8A959060-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 05:13:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08745 for ; Fri, 7 Nov 2003 05:13:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3c2-0005qM-3r for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 05:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7AD6l6022456 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 05:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3c2-0005q7-0C for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 05:13:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08718; Fri, 7 Nov 2003 05:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3bx-0002Sk-00; Fri, 07 Nov 2003 05:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI3bx-0002Sg-00; Fri, 07 Nov 2003 05:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3bx-0005oN-LW; Fri, 07 Nov 2003 05:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI3bu-0005oC-8I for simple@optimus.ietf.org; Fri, 07 Nov 2003 05:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08713 for ; Fri, 7 Nov 2003 05:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI3bq-0002Sd-00 for simple@ietf.org; Fri, 07 Nov 2003 05:12:54 -0500 Received: from smtp2.clb.oleane.net ([213.56.31.18]) by ietf-mx with esmtp (Exim 4.12) id 1AI3bq-0002SU-00 for simple@ietf.org; Fri, 07 Nov 2003 05:12:54 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp2.clb.oleane.net with SMTP id hA7ACOfo030422 for ; Fri, 7 Nov 2003 11:12:24 +0100 Message-ID: <042901c3a518$294e47a0$0601a8c0@www.oleane.com> From: "M Winkhler" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0426_01C3A520.8A959060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Simple] WiMAX Summit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 11:16:07 +0100 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_0426_01C3A520.8A959060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are WiMAX and WiFi complementary (local vs. metropolitan area = networking)?=20 When and how will WiMAX evolve towards mobility?=20 Can WiMAX be considered as a migration path to 4G?=20 How is addressed the interoperability challenge?=20 These questions, among others, will be addressed during the WiMAX = Summit, to be held in Paris on May 25 to 28, 2004.=20 A call for papers has been launched on-line at: http://www.upperside.fr/wimax04/wimax04intro.htm ------=_NextPart_000_0426_01C3A520.8A959060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Are WiMAX and WiFi complementary (local vs. = metropolitan=20 area networking)?
When and how will WiMAX evolve towards = mobility?=20
Can WiMAX be considered as a migration path to 4G?
How is = addressed the=20 interoperability challenge?

These questions, among others, will = be=20 addressed during the WiMAX = Summit, to=20 be held in Paris on May 25 to 28, 2004. =

A=20 call for papers has been launched on-line at:
http://www.uppe= rside.fr/wimax04/wimax04intro.htm
 
------=_NextPart_000_0426_01C3A520.8A959060-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 09:57:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16413; Fri, 7 Nov 2003 09:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI83r-00062d-00; Fri, 07 Nov 2003 09:58:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI83q-00062X-00; Fri, 07 Nov 2003 09:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI83k-0001To-Pg; Fri, 07 Nov 2003 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI83I-0001So-L0 for simple@optimus.ietf.org; Fri, 07 Nov 2003 09:57:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16378; Fri, 7 Nov 2003 09:57:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI83G-00061g-00; Fri, 07 Nov 2003 09:57:30 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AI83F-000610-00; Fri, 07 Nov 2003 09:57:30 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7EuwhL022333; Fri, 7 Nov 2003 09:56:58 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7Euvg09108; Fri, 7 Nov 2003 09:56:57 -0500 Message-ID: <3FABB2B9.3060003@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> In-Reply-To: <3FABA901.4040006@ecotroph.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 09:56:57 -0500 Content-Transfer-Encoding: 7bit >> I don't understand why the except clause in each permission statement >> should be dismissed while the separate exception list model can be >> supported. The exception list is restricted in its functionality to avoid the privacy problems caused by exception entries. Mixing the two means that both list types would need to be restricted as described. Also, having unbounded except lists makes processing more complicated since the simple row model no longer applies (it's no longer a relational table). >> >> 1) introducing a separate exception list but not supporting it, >> 2) introducing an except clause in each permission but not supporting >> it. > > > Neither do I. But in my opinion, both should be dismissed. I agree; I'm just trying to find the least harmful set of possible solutions. Mixing two models is by far, in my opinion, the worst option. > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 09:58:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16456 for ; Fri, 7 Nov 2003 09:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI83u-0001Za-9I for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 09:58:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7EwASa006042 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 09:58:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI83u-0001ZN-5p for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 09:58:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16413; Fri, 7 Nov 2003 09:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI83r-00062d-00; Fri, 07 Nov 2003 09:58:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI83q-00062X-00; Fri, 07 Nov 2003 09:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI83k-0001To-Pg; Fri, 07 Nov 2003 09:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI83I-0001So-L0 for simple@optimus.ietf.org; Fri, 07 Nov 2003 09:57:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16378; Fri, 7 Nov 2003 09:57:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI83G-00061g-00; Fri, 07 Nov 2003 09:57:30 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AI83F-000610-00; Fri, 07 Nov 2003 09:57:30 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7EuwhL022333; Fri, 7 Nov 2003 09:56:58 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7Euvg09108; Fri, 7 Nov 2003 09:56:57 -0500 Message-ID: <3FABB2B9.3060003@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> In-Reply-To: <3FABA901.4040006@ecotroph.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 09:56:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit >> I don't understand why the except clause in each permission statement >> should be dismissed while the separate exception list model can be >> supported. The exception list is restricted in its functionality to avoid the privacy problems caused by exception entries. Mixing the two means that both list types would need to be restricted as described. Also, having unbounded except lists makes processing more complicated since the simple row model no longer applies (it's no longer a relational table). >> >> 1) introducing a separate exception list but not supporting it, >> 2) introducing an except clause in each permission but not supporting >> it. > > > Neither do I. But in my opinion, both should be dismissed. I agree; I'm just trying to find the least harmful set of possible solutions. Mixing two models is by far, in my opinion, the worst option. > > -andy > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 10:02:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16574; Fri, 7 Nov 2003 10:02:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI87n-00066W-00; Fri, 07 Nov 2003 10:02:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI87n-00066S-00; Fri, 07 Nov 2003 10:02:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI87d-0001fG-75; Fri, 07 Nov 2003 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI87b-0001es-TW for simple@optimus.ietf.org; Fri, 07 Nov 2003 10:01:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16561; Fri, 7 Nov 2003 10:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI87Z-00066A-00; Fri, 07 Nov 2003 10:01:57 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AI87Z-000663-00; Fri, 07 Nov 2003 10:01:57 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7F1QhL022713; Fri, 7 Nov 2003 10:01:27 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7F1Qg09532; Fri, 7 Nov 2003 10:01:26 -0500 Message-ID: <3FABB3C6.1040605@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naoko ITO CC: Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> In-Reply-To: <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 10:01:26 -0500 Content-Transfer-Encoding: 7bit > I think a separate excepton list is very useful, corresponding to the > exact concept of 'black list.' It is not exactly a black list, although it can be used for that. That's why I called it an exception list. > Still, I'd like to have an except clause in a permission statment as > well, which can be used for a differenct purpose, i.e., giving > different permissions to some groups of the watchers. I'm sorry to sound like a broken record: People requesting features that break overall processing models should please have the kindness to provide motivation beyond "it could be useful". > > I don't understand why the except clause in each permission statement > should be dismissed while the separate exception list model can be > supported. > > 1) introducing a separate exception list but not supporting it, > 2) introducing an except clause in each permission but not supporting > it. See my other message. > > In the case of Option #1, the rule enforcer should drop all the > permission statements in the rule set in order to prevent those > should-be-excepted watchers from accidentally obtaining information, if > there is an exception statement which cannot be understood. i.e., no > permission is granted to anybody at all. In the case of Option #2, the > rule enforcer should drop the permission statements with unknown except > clauses, which still allows some watchers to obtain information. It > seems to me that both options give us the ways to ensure the > privacy-safe even if the rule enforcer does not support the except > mechanism, and rather the latter is more elastic or fault-tolerant. Or > is this just plausible? Please review the discussion on why this doesn't work when rules are composed from multiple sources. > > As for maintaining the row-model, I don't think the former model > maintains the row-model, while the entire rule set has no meaning if > the actual rule set once has an exception statement. If it means not > supporting the exception at all, the same thing can be done with the > except clause in each permission. The exception-list model does support the row model. Each rule has exactly one field value for each field, including the URI matching. > > I see no reason to dismiss the latter approach and would suggest to > keep both. If you're in Minneapolis, I'd be glad to explain this in more detail in person, since you couldn't be at the interim meeting, where we went over this for several hours... > > Regards, > ----- > Naoko Ito / NEC _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 10:02:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16612 for ; Fri, 7 Nov 2003 10:02:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI87r-0001kx-2u for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 10:02:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7F2FuN006745 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 10:02:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI87q-0001ki-Uf for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:02:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16574; Fri, 7 Nov 2003 10:02:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI87n-00066W-00; Fri, 07 Nov 2003 10:02:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI87n-00066S-00; Fri, 07 Nov 2003 10:02:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI87d-0001fG-75; Fri, 07 Nov 2003 10:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI87b-0001es-TW for simple@optimus.ietf.org; Fri, 07 Nov 2003 10:01:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16561; Fri, 7 Nov 2003 10:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI87Z-00066A-00; Fri, 07 Nov 2003 10:01:57 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AI87Z-000663-00; Fri, 07 Nov 2003 10:01:57 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7F1QhL022713; Fri, 7 Nov 2003 10:01:27 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7F1Qg09532; Fri, 7 Nov 2003 10:01:26 -0500 Message-ID: <3FABB3C6.1040605@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naoko ITO CC: Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> In-Reply-To: <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 10:01:26 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I think a separate excepton list is very useful, corresponding to the > exact concept of 'black list.' It is not exactly a black list, although it can be used for that. That's why I called it an exception list. > Still, I'd like to have an except clause in a permission statment as > well, which can be used for a differenct purpose, i.e., giving > different permissions to some groups of the watchers. I'm sorry to sound like a broken record: People requesting features that break overall processing models should please have the kindness to provide motivation beyond "it could be useful". > > I don't understand why the except clause in each permission statement > should be dismissed while the separate exception list model can be > supported. > > 1) introducing a separate exception list but not supporting it, > 2) introducing an except clause in each permission but not supporting > it. See my other message. > > In the case of Option #1, the rule enforcer should drop all the > permission statements in the rule set in order to prevent those > should-be-excepted watchers from accidentally obtaining information, if > there is an exception statement which cannot be understood. i.e., no > permission is granted to anybody at all. In the case of Option #2, the > rule enforcer should drop the permission statements with unknown except > clauses, which still allows some watchers to obtain information. It > seems to me that both options give us the ways to ensure the > privacy-safe even if the rule enforcer does not support the except > mechanism, and rather the latter is more elastic or fault-tolerant. Or > is this just plausible? Please review the discussion on why this doesn't work when rules are composed from multiple sources. > > As for maintaining the row-model, I don't think the former model > maintains the row-model, while the entire rule set has no meaning if > the actual rule set once has an exception statement. If it means not > supporting the exception at all, the same thing can be done with the > except clause in each permission. The exception-list model does support the row model. Each rule has exactly one field value for each field, including the URI matching. > > I see no reason to dismiss the latter approach and would suggest to > keep both. If you're in Minneapolis, I'd be glad to explain this in more detail in person, since you couldn't be at the interim meeting, where we went over this for several hours... > > Regards, > ----- > Naoko Ito / NEC _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 10:42:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19321; Fri, 7 Nov 2003 10:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8lQ-0006Zk-00; Fri, 07 Nov 2003 10:43:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI8lQ-0006Zh-00; Fri, 07 Nov 2003 10:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8lJ-00042q-JO; Fri, 07 Nov 2003 10:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8kQ-0003w4-Kb for simple@optimus.ietf.org; Fri, 07 Nov 2003 10:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19273; Fri, 7 Nov 2003 10:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8kO-0006Z1-00; Fri, 07 Nov 2003 10:42:04 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AI8kN-0006YI-00; Fri, 07 Nov 2003 10:42:03 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11300; Fri, 7 Nov 2003 10:41:30 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25598; Fri, 7 Nov 2003 10:41:31 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 10:41:30 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6097@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Naoko ITO Cc: Simple WG , geopriv@ietf.org Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:41:27 -0500 I've been on the receiving end of the "broken record". I do get it. I have some sympathy, but not a whole lot. Basically, I think that "it could be useful", is as good as you get, because no one has deployment experience. I think you are guilty of having an implantation in mind and forcing all requests through the lens of your implementation. One possible way to look at this is to observe that the messages sent could express something that is compact, where the implementation expands the message to a more explicit set of rules. In this example IF (big if) you have a list of users, you could have an arbitrarily complex set of AND/OR/EXCEPT/... operations, as long as the result was reducible to a set of users with the permission. That set could then be stored in your database. I do realize that in a sense, this kind of complexity is just an optimization, and thus subject to elimination in a first phase implementation. However, I think that the likelihood here is that it actually matters (all of a domain EXCEPT a couple of people). Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, November 07, 2003 10:01 AM > To: Naoko ITO > Cc: Simple WG; geopriv@ietf.org > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > > I think a separate excepton list is very useful, > corresponding to the > > exact concept of 'black list.' > > It is not exactly a black list, although it can be used for > that. That's > why I called it an exception list. > > > Still, I'd like to have an except clause in a permission statment as > > well, which can be used for a differenct purpose, i.e., giving > > different permissions to some groups of the watchers. > > I'm sorry to sound like a broken record: People requesting > features that > break overall processing models should please have the kindness to > provide motivation beyond "it could be useful". > > > > > I don't understand why the except clause in each permission > statement > > should be dismissed while the separate exception list model can be > > supported. > > > > 1) introducing a separate exception list but not supporting it, > > 2) introducing an except clause in each permission but not > supporting > > it. > > See my other message. > > > > > In the case of Option #1, the rule enforcer should drop all the > > permission statements in the rule set in order to prevent those > > should-be-excepted watchers from accidentally obtaining > information, if > > there is an exception statement which cannot be understood. i.e., no > > permission is granted to anybody at all. In the case of > Option #2, the > > rule enforcer should drop the permission statements with > unknown except > > clauses, which still allows some watchers to obtain information. It > > seems to me that both options give us the ways to ensure the > > privacy-safe even if the rule enforcer does not support the except > > mechanism, and rather the latter is more elastic or > fault-tolerant. Or > > is this just plausible? > > Please review the discussion on why this doesn't work when rules are > composed from multiple sources. > > > > > > As for maintaining the row-model, I don't think the former model > > maintains the row-model, while the entire rule set has no meaning if > > the actual rule set once has an exception statement. If it means not > > supporting the exception at all, the same thing can be done with the > > except clause in each permission. > > The exception-list model does support the row model. Each rule has > exactly one field value for each field, including the URI matching. > > > > > I see no reason to dismiss the latter approach and would suggest to > > keep both. > > If you're in Minneapolis, I'd be glad to explain this in more > detail in > person, since you couldn't be at the interim meeting, where > we went over > this for several hours... > > > > > Regards, > > ----- > > Naoko Ito / NEC > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 10:43:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19370 for ; Fri, 7 Nov 2003 10:43:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8lU-000469-68 for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 10:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7FhCVw015749 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 10:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8lU-00045w-2v for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19321; Fri, 7 Nov 2003 10:42:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8lQ-0006Zk-00; Fri, 07 Nov 2003 10:43:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI8lQ-0006Zh-00; Fri, 07 Nov 2003 10:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8lJ-00042q-JO; Fri, 07 Nov 2003 10:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8kQ-0003w4-Kb for simple@optimus.ietf.org; Fri, 07 Nov 2003 10:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19273; Fri, 7 Nov 2003 10:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8kO-0006Z1-00; Fri, 07 Nov 2003 10:42:04 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AI8kN-0006YI-00; Fri, 07 Nov 2003 10:42:03 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11300; Fri, 7 Nov 2003 10:41:30 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25598; Fri, 7 Nov 2003 10:41:31 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 10:41:30 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6097@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Naoko ITO Cc: Simple WG , geopriv@ietf.org Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:41:27 -0500 I've been on the receiving end of the "broken record". I do get it. I have some sympathy, but not a whole lot. Basically, I think that "it could be useful", is as good as you get, because no one has deployment experience. I think you are guilty of having an implantation in mind and forcing all requests through the lens of your implementation. One possible way to look at this is to observe that the messages sent could express something that is compact, where the implementation expands the message to a more explicit set of rules. In this example IF (big if) you have a list of users, you could have an arbitrarily complex set of AND/OR/EXCEPT/... operations, as long as the result was reducible to a set of users with the permission. That set could then be stored in your database. I do realize that in a sense, this kind of complexity is just an optimization, and thus subject to elimination in a first phase implementation. However, I think that the likelihood here is that it actually matters (all of a domain EXCEPT a couple of people). Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, November 07, 2003 10:01 AM > To: Naoko ITO > Cc: Simple WG; geopriv@ietf.org > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > > I think a separate excepton list is very useful, > corresponding to the > > exact concept of 'black list.' > > It is not exactly a black list, although it can be used for > that. That's > why I called it an exception list. > > > Still, I'd like to have an except clause in a permission statment as > > well, which can be used for a differenct purpose, i.e., giving > > different permissions to some groups of the watchers. > > I'm sorry to sound like a broken record: People requesting > features that > break overall processing models should please have the kindness to > provide motivation beyond "it could be useful". > > > > > I don't understand why the except clause in each permission > statement > > should be dismissed while the separate exception list model can be > > supported. > > > > 1) introducing a separate exception list but not supporting it, > > 2) introducing an except clause in each permission but not > supporting > > it. > > See my other message. > > > > > In the case of Option #1, the rule enforcer should drop all the > > permission statements in the rule set in order to prevent those > > should-be-excepted watchers from accidentally obtaining > information, if > > there is an exception statement which cannot be understood. i.e., no > > permission is granted to anybody at all. In the case of > Option #2, the > > rule enforcer should drop the permission statements with > unknown except > > clauses, which still allows some watchers to obtain information. It > > seems to me that both options give us the ways to ensure the > > privacy-safe even if the rule enforcer does not support the except > > mechanism, and rather the latter is more elastic or > fault-tolerant. Or > > is this just plausible? > > Please review the discussion on why this doesn't work when rules are > composed from multiple sources. > > > > > > As for maintaining the row-model, I don't think the former model > > maintains the row-model, while the entire rule set has no meaning if > > the actual rule set once has an exception statement. If it means not > > supporting the exception at all, the same thing can be done with the > > except clause in each permission. > > The exception-list model does support the row model. Each rule has > exactly one field value for each field, including the URI matching. > > > > > I see no reason to dismiss the latter approach and would suggest to > > keep both. > > If you're in Minneapolis, I'd be glad to explain this in more > detail in > person, since you couldn't be at the interim meeting, where > we went over > this for several hours... > > > > > Regards, > > ----- > > Naoko Ito / NEC > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 10:50:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19537; Fri, 7 Nov 2003 10:50:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8sJ-0006f7-00; Fri, 07 Nov 2003 10:50:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI8sI-0006f4-00; Fri, 07 Nov 2003 10:50:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8s6-0004N0-NK; Fri, 07 Nov 2003 10:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8rM-0004Lp-7E for simple@optimus.ietf.org; Fri, 07 Nov 2003 10:49:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19499; Fri, 7 Nov 2003 10:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8rJ-0006ds-00; Fri, 07 Nov 2003 10:49:13 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AI8rI-0006dT-00; Fri, 07 Nov 2003 10:49:13 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11614; Fri, 7 Nov 2003 10:48:40 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26770; Fri, 7 Nov 2003 10:48:42 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 10:48:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6099@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Naoko ITO Cc: Simple WG , geopriv@ietf.org Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:48:41 -0500 oh well. Not enough attention paid to spell check! implantation = implementation Sorry Brian > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, November 07, 2003 10:41 AM > To: 'Henning Schulzrinne'; Naoko ITO > Cc: Simple WG; geopriv@ietf.org > Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth > > > I've been on the receiving end of the "broken record". > I do get it. I have some sympathy, but not a whole lot. > Basically, I think that "it could be useful", is as > good as you get, because no one has deployment experience. > I think you are guilty of having an implantation in mind > and forcing all requests through the lens of your > implementation. > > One possible way to look at this is to observe that the > messages sent could express something that is compact, > where the implementation expands the message to a more > explicit set of rules. In this example IF (big if) > you have a list of users, you could have an arbitrarily > complex set of AND/OR/EXCEPT/... operations, as long > as the result was reducible to a set of users with > the permission. That set could then be stored in your > database. > > I do realize that in a sense, this kind of complexity is > just an opimization, and thus subject to elimination > in a first phase implementation. However, I think > that the likelihood here is that it actually matters > (all of a domain EXCEPT a couple of people). > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, November 07, 2003 10:01 AM > > To: Naoko ITO > > Cc: Simple WG; geopriv@ietf.org > > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > > > > > I think a separate excepton list is very useful, > > corresponding to the > > > exact concept of 'black list.' > > > > It is not exactly a black list, although it can be used for > > that. That's > > why I called it an exception list. > > > > > Still, I'd like to have an except clause in a permission > statment as > > > well, which can be used for a differenct purpose, i.e., giving > > > different permissions to some groups of the watchers. > > > > I'm sorry to sound like a broken record: People requesting > > features that > > break overall processing models should please have the kindness to > > provide motivation beyond "it could be useful". > > > > > > > > I don't understand why the except clause in each permission > > statement > > > should be dismissed while the separate exception list model can be > > > supported. > > > > > > 1) introducing a separate exception list but not supporting it, > > > 2) introducing an except clause in each permission but not > > supporting > > > it. > > > > See my other message. > > > > > > > > In the case of Option #1, the rule enforcer should drop all the > > > permission statements in the rule set in order to prevent those > > > should-be-excepted watchers from accidentally obtaining > > information, if > > > there is an exception statement which cannot be > understood. i.e., no > > > permission is granted to anybody at all. In the case of > > Option #2, the > > > rule enforcer should drop the permission statements with > > unknown except > > > clauses, which still allows some watchers to obtain > information. It > > > seems to me that both options give us the ways to ensure the > > > privacy-safe even if the rule enforcer does not support the except > > > mechanism, and rather the latter is more elastic or > > fault-tolerant. Or > > > is this just plausible? > > > > Please review the discussion on why this doesn't work when > rules are > > composed from multiple sources. > > > > > > > > > > As for maintaining the row-model, I don't think the former model > > > maintains the row-model, while the entire rule set has no > meaning if > > > the actual rule set once has an exception statement. If > it means not > > > supporting the exception at all, the same thing can be > done with the > > > except clause in each permission. > > > > The exception-list model does support the row model. Each rule has > > exactly one field value for each field, including the URI matching. > > > > > > > > I see no reason to dismiss the latter approach and would > suggest to > > > keep both. > > > > If you're in Minneapolis, I'd be glad to explain this in more > > detail in > > person, since you couldn't be at the interim meeting, where > > we went over > > this for several hours... > > > > > > > > Regards, > > > ----- > > > Naoko Ito / NEC > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 10:50:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19612 for ; Fri, 7 Nov 2003 10:50:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8sN-0004TT-5g for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 10:50:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7FoJFo017195 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 10:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8sN-0004TG-1o for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 10:50:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19537; Fri, 7 Nov 2003 10:50:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8sJ-0006f7-00; Fri, 07 Nov 2003 10:50:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI8sI-0006f4-00; Fri, 07 Nov 2003 10:50:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8s6-0004N0-NK; Fri, 07 Nov 2003 10:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI8rM-0004Lp-7E for simple@optimus.ietf.org; Fri, 07 Nov 2003 10:49:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19499; Fri, 7 Nov 2003 10:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI8rJ-0006ds-00; Fri, 07 Nov 2003 10:49:13 -0500 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 1AI8rI-0006dT-00; Fri, 07 Nov 2003 10:49:13 -0500 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11614; Fri, 7 Nov 2003 10:48:40 -0500 (EST) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26770; Fri, 7 Nov 2003 10:48:42 -0500 (EST) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 10:48:41 -0500 Message-ID: <313680C9A886D511A06000204840E1CF070B6099@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , Naoko ITO Cc: Simple WG , geopriv@ietf.org Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:48:41 -0500 oh well. Not enough attention paid to spell check! implantation = implementation Sorry Brian > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Friday, November 07, 2003 10:41 AM > To: 'Henning Schulzrinne'; Naoko ITO > Cc: Simple WG; geopriv@ietf.org > Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth > > > I've been on the receiving end of the "broken record". > I do get it. I have some sympathy, but not a whole lot. > Basically, I think that "it could be useful", is as > good as you get, because no one has deployment experience. > I think you are guilty of having an implantation in mind > and forcing all requests through the lens of your > implementation. > > One possible way to look at this is to observe that the > messages sent could express something that is compact, > where the implementation expands the message to a more > explicit set of rules. In this example IF (big if) > you have a list of users, you could have an arbitrarily > complex set of AND/OR/EXCEPT/... operations, as long > as the result was reducible to a set of users with > the permission. That set could then be stored in your > database. > > I do realize that in a sense, this kind of complexity is > just an opimization, and thus subject to elimination > in a first phase implementation. However, I think > that the likelihood here is that it actually matters > (all of a domain EXCEPT a couple of people). > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, November 07, 2003 10:01 AM > > To: Naoko ITO > > Cc: Simple WG; geopriv@ietf.org > > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > > > > > I think a separate excepton list is very useful, > > corresponding to the > > > exact concept of 'black list.' > > > > It is not exactly a black list, although it can be used for > > that. That's > > why I called it an exception list. > > > > > Still, I'd like to have an except clause in a permission > statment as > > > well, which can be used for a differenct purpose, i.e., giving > > > different permissions to some groups of the watchers. > > > > I'm sorry to sound like a broken record: People requesting > > features that > > break overall processing models should please have the kindness to > > provide motivation beyond "it could be useful". > > > > > > > > I don't understand why the except clause in each permission > > statement > > > should be dismissed while the separate exception list model can be > > > supported. > > > > > > 1) introducing a separate exception list but not supporting it, > > > 2) introducing an except clause in each permission but not > > supporting > > > it. > > > > See my other message. > > > > > > > > In the case of Option #1, the rule enforcer should drop all the > > > permission statements in the rule set in order to prevent those > > > should-be-excepted watchers from accidentally obtaining > > information, if > > > there is an exception statement which cannot be > understood. i.e., no > > > permission is granted to anybody at all. In the case of > > Option #2, the > > > rule enforcer should drop the permission statements with > > unknown except > > > clauses, which still allows some watchers to obtain > information. It > > > seems to me that both options give us the ways to ensure the > > > privacy-safe even if the rule enforcer does not support the except > > > mechanism, and rather the latter is more elastic or > > fault-tolerant. Or > > > is this just plausible? > > > > Please review the discussion on why this doesn't work when > rules are > > composed from multiple sources. > > > > > > > > > > As for maintaining the row-model, I don't think the former model > > > maintains the row-model, while the entire rule set has no > meaning if > > > the actual rule set once has an exception statement. If > it means not > > > supporting the exception at all, the same thing can be > done with the > > > except clause in each permission. > > > > The exception-list model does support the row model. Each rule has > > exactly one field value for each field, including the URI matching. > > > > > > > > I see no reason to dismiss the latter approach and would > suggest to > > > keep both. > > > > If you're in Minneapolis, I'd be glad to explain this in more > > detail in > > person, since you couldn't be at the interim meeting, where > > we went over > > this for several hours... > > > > > > > > Regards, > > > ----- > > > Naoko Ito / NEC > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 11:29:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20984; Fri, 7 Nov 2003 11:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9Uu-00079o-00; Fri, 07 Nov 2003 11:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI9Uu-00079l-00; Fri, 07 Nov 2003 11:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Un-0006n6-GI; Fri, 07 Nov 2003 11:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9UN-0006ly-K0 for simple@optimus.ietf.org; Fri, 07 Nov 2003 11:29:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20948 for ; Fri, 7 Nov 2003 11:29:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9UM-00079L-00 for simple@ietf.org; Fri, 07 Nov 2003 11:29:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AI9UL-000799-00 for simple@ietf.org; Fri, 07 Nov 2003 11:29:34 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7GTKIc005322; Fri, 7 Nov 2003 10:29:27 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FABC854.5060505@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: MRSP: URL vs RUI (was Re: [Simple] Comments on message-sessions-02) References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 10:29:08 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Some comments below are more serious that others. Please respond to the ones that you think will cause some discussion is separate emails: > > - General: > - Should we use URI in the text instead of URL? The RFC that is referenced talks about URI (note if the references section, it wrongly says URL) We actually decided to change from URI to URL some time ago. RFC2396 speaks to URLs and URNsas well as URIs, and implies that a URI is either a locater or a name. The MSRP scheme seems to me to more fit the URL definition than the URN definition. While a URL is a kind of URI, I don't see how it serves us to move back to the more general term. You are correct about the title in the RFC reference being wrong. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 11:30:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21032 for ; Fri, 7 Nov 2003 11:30:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Ux-0006qq-2m for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 11:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7GUBer026330 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 11:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Uw-0006qb-Uf for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 11:30:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20984; Fri, 7 Nov 2003 11:29:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9Uu-00079o-00; Fri, 07 Nov 2003 11:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AI9Uu-00079l-00; Fri, 07 Nov 2003 11:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9Un-0006n6-GI; Fri, 07 Nov 2003 11:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI9UN-0006ly-K0 for simple@optimus.ietf.org; Fri, 07 Nov 2003 11:29:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20948 for ; Fri, 7 Nov 2003 11:29:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI9UM-00079L-00 for simple@ietf.org; Fri, 07 Nov 2003 11:29:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AI9UL-000799-00 for simple@ietf.org; Fri, 07 Nov 2003 11:29:34 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7GTKIc005322; Fri, 7 Nov 2003 10:29:27 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FABC854.5060505@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: MRSP: URL vs RUI (was Re: [Simple] Comments on message-sessions-02) References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 10:29:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Some comments below are more serious that others. Please respond to the ones that you think will cause some discussion is separate emails: > > - General: > - Should we use URI in the text instead of URL? The RFC that is referenced talks about URI (note if the references section, it wrongly says URL) We actually decided to change from URI to URL some time ago. RFC2396 speaks to URLs and URNsas well as URIs, and implies that a URI is either a locater or a name. The MSRP scheme seems to me to more fit the URL definition than the URN definition. While a URL is a kind of URI, I don't see how it serves us to move back to the more general term. You are correct about the title in the RFC reference being wrong. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 12:16:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24689; Fri, 7 Nov 2003 12:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAEP-0007ka-00; Fri, 07 Nov 2003 12:17:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIAEP-0007kX-00; Fri, 07 Nov 2003 12:17:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAEG-0001VT-TN; Fri, 07 Nov 2003 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIADv-0001UZ-CA for simple@optimus.ietf.org; Fri, 07 Nov 2003 12:16:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24455 for ; Fri, 7 Nov 2003 12:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIADs-0007jz-00 for simple@ietf.org; Fri, 07 Nov 2003 12:16:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AIADr-0007jw-00 for simple@ietf.org; Fri, 07 Nov 2003 12:16:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7HGOIc009370; Fri, 7 Nov 2003 11:16:35 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FABD35C.1060006@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 11:16:12 -0600 Content-Transfer-Encoding: 7bit Hi--I addressed some points in separate emails. Others inline: hisham.khartabil@nokia.com wrote: [...] > - Section 4: > - It should mention that a SEND request is also used as a keepalive mechanism (it is stays that way)- I think that is only coincidentally true. Any end-to-end request serves as a keepalive. If we were, in the future, to add some new end-to-end method (Not that I am proposing we do!) then I think that new method could _also_ serve as a keepalive. So, really, the keepalive mechanism is something to the effect of "periodically send end-to-end traffic" It just so happens that the only current way to do this is with SEND. I plan to re-word some of the inactivity timeout text to make this more clear in the next version (assuming we don't decide to change it.) > - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip Agreed. > - This section also talks about inactivity timer, and says that that hosting device invalidates the session state when timer expires. Why is it just the hosting device? Let me turn that question around. Why would any other device need to? When the hosting device closes the session, the endpoints will learn of it in short order as they get their connections closed. So will a visiting relay, for that matter (although I do think we have an open item on whether visiting relays should have to worry about the timer.) > > - Section 5.1: > - Is this section normative? It have normative text like SHOULD and SHOULD not. Yes, section 5.1 is intended to be normative, although it contains no statements stronger than SHOULD. But we mean those SHOULDs just as much as any other SHOULDs in the document. :-) > > - Section 5.2: > - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mime-type. In this way, the other endpoint does not use that session to send normal messages. That is an interesting approach. But I think we may have overlap in types that are allowed on an IM session, and types that are allowed on a file transfer session. What if I want to transfer a large file of type text/plain? > - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session alive. Eg: if you have a session for text/plain and you create a second one to send a 5gb video file, the text/plain session can be used to keepalive both sessions since they are both to the same remote end. > I really don't like forcing a relay to know that two sessions involve the same pair of endpoints. > - Section 6: > - Reference to RFC 3264 is probably needed here. Agreed. > - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we need to include the session attribute carrying the session URI again? What do we set the direction attribute to, if set at all in the second offer? Some text and examples for this issue is needed. Interesting question. It may make sense to publish a set of use cases, much as we have done with the SIP call flows document. I wonder if that belongs in the core document, or in a separate one? > > - Section 6.1: > - The example is missing the accept-types attribute. The example in 6.1 is explicitly just an m-line, not an entire SDP document. > > - Section 6.3: > - the BNF provided allows accept-types to have multiple *. eg: a=accept-types: * * * > It should be fixed to something like: > > accept-types = accept-types-label ":" format-list > accept-types-label = "accept-types" > format-list = "*" / format-entries > format-entries = format-entry *( SP format-entry) > format-entry = (type "/" subtype) > type = token > subtype = token > That does not seem to allow for something like "a=accept-types: message/cpim text/plain *", which is semantically meaningful. I can change the syntax to only allow one "*", but do we really care? "* * *" may be silly, but it can still be interpreted reasonably. > - Need to reference the ABNF RFC OK > - This section should mention that the offerer should use the accept-types in the answer to send. OK > > - Section 6.4: > - "format entries from the m-line SHOULD NOT be repeated in this attribute". Should say accept-types instead of m-lines. OK [...] > - Section 7.1.2: > - Why is there text describing the use of SRV if no port is present? The port is mandatory and therefore resolving should fail if no port is present. INVITE requests would then be rejected. If we want SRV, then we need to relax the MUST for port. > It is not mandatory for a URL that designates a relay that is handed to an endpoint out-of-band. (For example, when a user configures a client to use a relay.) > - Section 7.4.1: > - The last step before section 7.4.2 talks about Exp header. That should not be there. There is no Exp header in a 200 response to a visit. OK > > - Section 7.4.3: > - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the very large message being sent again (long messages have the potential to falsely timing out and the sender gets a 500 response). Agreed, assuming consensus agrees on the following open issue. > - Open issue: NO. > > - Section 7.4.4: > - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message session. > - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200 responses to SENDs until it has received a 200 for the SIP BYE. The recipient of the SIP BYE should cease responding to SENDs as soon as it sent a 200 for the SIP BYE. This allows more outstanding SENDs to complete. > I need to think about this one. > - Section 7.4.5: > - Open issue: I don't understand the open issue. There is no explicit "unvisit" semantic. The visiting relay indirectly discovers a session has ended. > - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it. > OK > - Section 7.5.1: > - Steps for a Relay receiving a BIND request. Step 3 refers to section 7.4.5, but that section talks about inactivity timer. OK > - How dies the host communicate the pre-visit timer to the visitor? It doesn't. The point is not to tell the visitor that is has X time to connect, we assume the visitor will connect as fast as it can. The pre-visit timer merely tells the relay how long we want it to wait before giving up. > - Steps for a Relay receiving a VISIT request. The last step should mention that the pre-visit timer is no longer valid. OK > > - Section 7.7.2: > - Need to mention that SEND is also used for keepalive. Or preferably, we can define an new method like KEEPALIVE as been discussed. If not, then the SHOULD contain MIME should be relaxed. See previous comment. > > - Section 8: > - Many examples don't have the CFLF between header and body in MSRP messages. Oops. OK. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 12:17:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24951 for ; Fri, 7 Nov 2003 12:17:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAES-0001Ya-1J for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 12:17:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7HHCXe005978 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 12:17:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAER-0001YD-T7 for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 12:17:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24689; Fri, 7 Nov 2003 12:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIAEP-0007ka-00; Fri, 07 Nov 2003 12:17:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIAEP-0007kX-00; Fri, 07 Nov 2003 12:17:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIAEG-0001VT-TN; Fri, 07 Nov 2003 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIADv-0001UZ-CA for simple@optimus.ietf.org; Fri, 07 Nov 2003 12:16:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24455 for ; Fri, 7 Nov 2003 12:16:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIADs-0007jz-00 for simple@ietf.org; Fri, 07 Nov 2003 12:16:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AIADr-0007jw-00 for simple@ietf.org; Fri, 07 Nov 2003 12:16:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7HGOIc009370; Fri, 7 Nov 2003 11:16:35 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FABD35C.1060006@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 11:16:12 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi--I addressed some points in separate emails. Others inline: hisham.khartabil@nokia.com wrote: [...] > - Section 4: > - It should mention that a SEND request is also used as a keepalive mechanism (it is stays that way)- I think that is only coincidentally true. Any end-to-end request serves as a keepalive. If we were, in the future, to add some new end-to-end method (Not that I am proposing we do!) then I think that new method could _also_ serve as a keepalive. So, really, the keepalive mechanism is something to the effect of "periodically send end-to-end traffic" It just so happens that the only current way to do this is with SEND. I plan to re-word some of the inactivity timeout text to make this more clear in the next version (assuming we don't decide to change it.) > - It mentions that a session is ended with a SIP BYE. It should say that a session is ended using the signalling channel, for example a BYE is used in sip Agreed. > - This section also talks about inactivity timer, and says that that hosting device invalidates the session state when timer expires. Why is it just the hosting device? Let me turn that question around. Why would any other device need to? When the hosting device closes the session, the endpoints will learn of it in short order as they get their connections closed. So will a visiting relay, for that matter (although I do think we have an open item on whether visiting relays should have to worry about the timer.) > > - Section 5.1: > - Is this section normative? It have normative text like SHOULD and SHOULD not. Yes, section 5.1 is intended to be normative, although it contains no statements stronger than SHOULD. But we mean those SHOULDs just as much as any other SHOULDs in the document. :-) > > - Section 5.2: > - Open issue: the attribute accept-type can be used to restrict the use of a message session. So if a session was created to send mpeg video. The accept-types attribute should only carry that mime-type. In this way, the other endpoint does not use that session to send normal messages. That is an interesting approach. But I think we may have overlap in types that are allowed on an IM session, and types that are allowed on a file transfer session. What if I want to transfer a large file of type text/plain? > - Open issue: About avoiding timeouts for longer requests. Can we say that if there are more than 1 session to the same endpoint, then keeping any of the session alive keeps all the session alive. Eg: if you have a session for text/plain and you create a second one to send a 5gb video file, the text/plain session can be used to keepalive both sessions since they are both to the same remote end. > I really don't like forcing a relay to know that two sessions involve the same pair of endpoints. > - Section 6: > - Reference to RFC 3264 is probably needed here. Agreed. > - I had trouble figuring out how to send a second offer after the first offer/answer exchange, for example to add a new mime type of to add a new session. How does the new offer look like? Do we need to include the session attribute carrying the session URI again? What do we set the direction attribute to, if set at all in the second offer? Some text and examples for this issue is needed. Interesting question. It may make sense to publish a set of use cases, much as we have done with the SIP call flows document. I wonder if that belongs in the core document, or in a separate one? > > - Section 6.1: > - The example is missing the accept-types attribute. The example in 6.1 is explicitly just an m-line, not an entire SDP document. > > - Section 6.3: > - the BNF provided allows accept-types to have multiple *. eg: a=accept-types: * * * > It should be fixed to something like: > > accept-types = accept-types-label ":" format-list > accept-types-label = "accept-types" > format-list = "*" / format-entries > format-entries = format-entry *( SP format-entry) > format-entry = (type "/" subtype) > type = token > subtype = token > That does not seem to allow for something like "a=accept-types: message/cpim text/plain *", which is semantically meaningful. I can change the syntax to only allow one "*", but do we really care? "* * *" may be silly, but it can still be interpreted reasonably. > - Need to reference the ABNF RFC OK > - This section should mention that the offerer should use the accept-types in the answer to send. OK > > - Section 6.4: > - "format entries from the m-line SHOULD NOT be repeated in this attribute". Should say accept-types instead of m-lines. OK [...] > - Section 7.1.2: > - Why is there text describing the use of SRV if no port is present? The port is mandatory and therefore resolving should fail if no port is present. INVITE requests would then be rejected. If we want SRV, then we need to relax the MUST for port. > It is not mandatory for a URL that designates a relay that is handed to an endpoint out-of-band. (For example, when a user configures a client to use a relay.) > - Section 7.4.1: > - The last step before section 7.4.2 talks about Exp header. That should not be there. There is no Exp header in a 200 response to a visit. OK > > - Section 7.4.3: > - In step 5 "The endpoint MAY attempt to send the message content again" Should we remove this text? If the message sending fails, so be it. The user can choose to send it again. This avoids the very large message being sent again (long messages have the potential to falsely timing out and the sender gets a 500 response). Agreed, assuming consensus agrees on the following open issue. > - Open issue: NO. > > - Section 7.4.4: > - an INVITE request can also terminate a message session (port 0). That should be noted along side the SIP BYE example. Otherwise implementers will think that only a BYE can terminate a message session. > - About when to stop sending responses to SEND request. I would require that the initiator of the BYE (or any signalling request that terminates the message session) should continue to send 200 responses to SENDs until it has received a 200 for the SIP BYE. The recipient of the SIP BYE should cease responding to SENDs as soon as it sent a 200 for the SIP BYE. This allows more outstanding SENDs to complete. > I need to think about this one. > - Section 7.4.5: > - Open issue: I don't understand the open issue. There is no explicit "unvisit" semantic. The visiting relay indirectly discovers a session has ended. > - "Each endpoint MUST keep a similar timer..." This sounds like a third timer is present. Need to better tie this paragraph with the one before it. > OK > - Section 7.5.1: > - Steps for a Relay receiving a BIND request. Step 3 refers to section 7.4.5, but that section talks about inactivity timer. OK > - How dies the host communicate the pre-visit timer to the visitor? It doesn't. The point is not to tell the visitor that is has X time to connect, we assume the visitor will connect as fast as it can. The pre-visit timer merely tells the relay how long we want it to wait before giving up. > - Steps for a Relay receiving a VISIT request. The last step should mention that the pre-visit timer is no longer valid. OK > > - Section 7.7.2: > - Need to mention that SEND is also used for keepalive. Or preferably, we can define an new method like KEEPALIVE as been discussed. If not, then the SHOULD contain MIME should be relaxed. See previous comment. > > - Section 8: > - Many examples don't have the CFLF between header and body in MSRP messages. Oops. OK. > > Regards, > Hisham > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 13:35:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28184; Fri, 7 Nov 2003 13:35:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBRt-0000xA-00; Fri, 07 Nov 2003 13:35:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBRt-0000x7-00; Fri, 07 Nov 2003 13:35:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBRm-0005hl-Am; Fri, 07 Nov 2003 13:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBR3-0005gu-Tu for simple@optimus.ietf.org; Fri, 07 Nov 2003 13:34:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28152; Fri, 7 Nov 2003 13:34:06 -0500 (EST) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBR1-0000wb-00; Fri, 07 Nov 2003 13:34:15 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AIBR1-0000wY-00; Fri, 07 Nov 2003 13:34:15 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7IY64t016291; Fri, 7 Nov 2003 10:34:06 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7IY30O012786; Fri, 7 Nov 2003 10:34:04 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <313680C9A886D511A06000204840E1CF070B6097@whq-msgusr-02.pit.comms.marconi. com> References: <313680C9A886D511A06000204840E1CF070B6097@whq-msgusr-02.pit.comms.marconi. com> To: "Rosen, Brian" , "'Henning Schulzrinne'" , Naoko ITO Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth Cc: Simple WG , geopriv@ietf.org Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:34:05 -0800 At 10:41 AM -0500 11/07/2003, Rosen, Brian wrote: >I've been on the receiving end of the "broken record". >I do get it. I have some sympathy, but not a whole lot. >Basically, I think that "it could be useful", is as >good as you get, because no one has deployment experience. >I think you are guilty of having an implantation in mind >and forcing all requests through the lens of your >implementation. As just another bozo on this bus, let me say that I don't think that I have the same lens as Henning (and certainly don't have the same implementation in mind), but he and I share some concerns. I agree with you that no one has deployment experience for this and that we will no doubt learn something from that experience. I question, though, whether that means the right choice is "put things in that might be needed" or "put things in we know we need, then see what we're missing". To take up your point on implementation, I note that folks do seem to be assuming a connection between the UI and the protocol behavior. I can easily see a UI saying "Grant all buddies civil geolocation data at City level, except $ex-spouse, who should get my timezone" and translating that as a grant of timezone to all buddies and a second grant of City to each of those that isn't the ex-spouse. From the user point of view, it's an "except", where from the protocol point of view it is additive permissions. There is no question that there are engineering trade-offs here. You gain simplicity and have an easy method to ensure maximal privacy, but you may get increased object size and you may need to structure group data in ways that ensure it fits this model reasonably efficiently. Neither choice is perfect, but this one does have some very useful characteristics for a large number of GeoPriv cases. There may be other usage patterns in other uses of XCAP that mean we can't have a perfect fit, but if we can keep that split to a minimum, I think it's worth it. regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 13:35:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28227 for ; Fri, 7 Nov 2003 13:35:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBRx-0005kB-1x for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 13:35:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7IZDZL022073 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 13:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBRw-0005jw-Ut for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28184; Fri, 7 Nov 2003 13:35:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBRt-0000xA-00; Fri, 07 Nov 2003 13:35:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBRt-0000x7-00; Fri, 07 Nov 2003 13:35:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBRm-0005hl-Am; Fri, 07 Nov 2003 13:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBR3-0005gu-Tu for simple@optimus.ietf.org; Fri, 07 Nov 2003 13:34:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28152; Fri, 7 Nov 2003 13:34:06 -0500 (EST) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBR1-0000wb-00; Fri, 07 Nov 2003 13:34:15 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AIBR1-0000wY-00; Fri, 07 Nov 2003 13:34:15 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7IY64t016291; Fri, 7 Nov 2003 10:34:06 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7IY30O012786; Fri, 7 Nov 2003 10:34:04 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <313680C9A886D511A06000204840E1CF070B6097@whq-msgusr-02.pit.comms.marconi. com> References: <313680C9A886D511A06000204840E1CF070B6097@whq-msgusr-02.pit.comms.marconi. com> To: "Rosen, Brian" , "'Henning Schulzrinne'" , Naoko ITO Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth Cc: Simple WG , geopriv@ietf.org Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 10:34:05 -0800 At 10:41 AM -0500 11/07/2003, Rosen, Brian wrote: >I've been on the receiving end of the "broken record". >I do get it. I have some sympathy, but not a whole lot. >Basically, I think that "it could be useful", is as >good as you get, because no one has deployment experience. >I think you are guilty of having an implantation in mind >and forcing all requests through the lens of your >implementation. As just another bozo on this bus, let me say that I don't think that I have the same lens as Henning (and certainly don't have the same implementation in mind), but he and I share some concerns. I agree with you that no one has deployment experience for this and that we will no doubt learn something from that experience. I question, though, whether that means the right choice is "put things in that might be needed" or "put things in we know we need, then see what we're missing". To take up your point on implementation, I note that folks do seem to be assuming a connection between the UI and the protocol behavior. I can easily see a UI saying "Grant all buddies civil geolocation data at City level, except $ex-spouse, who should get my timezone" and translating that as a grant of timezone to all buddies and a second grant of City to each of those that isn't the ex-spouse. From the user point of view, it's an "except", where from the protocol point of view it is additive permissions. There is no question that there are engineering trade-offs here. You gain simplicity and have an easy method to ensure maximal privacy, but you may get increased object size and you may need to structure group data in ways that ensure it fits this model reasonably efficiently. Neither choice is perfect, but this one does have some very useful characteristics for a large number of GeoPriv cases. There may be other usage patterns in other uses of XCAP that mean we can't have a perfect fit, but if we can keep that split to a minimum, I think it's worth it. regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 15:01:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04238; Fri, 7 Nov 2003 15:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICo2-0002DJ-00; Fri, 07 Nov 2003 15:02:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICo1-0002DG-00; Fri, 07 Nov 2003 15:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICnx-0004T8-Pw; Fri, 07 Nov 2003 15:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICnn-0004SX-Br for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04229; Fri, 7 Nov 2003 15:01:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICnj-0002D0-00; Fri, 07 Nov 2003 15:01:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AICnj-0002Cx-00; Fri, 07 Nov 2003 15:01:47 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7K0wca013652; Fri, 7 Nov 2003 15:00:58 -0500 (EST) Message-ID: <3FABF9F8.6050400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC0406@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0406@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:00:56 -0500 Content-Transfer-Encoding: 7bit Sure, not every identity system supports the notions of a user and a domain, but a LOT of them do. In any one system in which geopriv gets used, you will have to know the set of identity types that are in use. Any one system will support only a finite number of authentication systems, each of which only supports some number of identities. Even if you assume an authentication system that can support any type of identity, the geopriv processing would seem to require you to understand the type of identity, in order to perform an equality operation on it. As such, I dont see the issue in allowing geopriv to support domain based identifiers. If a user is authenticated with a particular identity that doesnt have the concept of a domain, that user wouldn't be a match for any of operations. -Jonathan R. Tschofenig Hannes wrote: > hi jonathan, > > the problem with your approach is the following: you are simply assuming an > email type of identity (which is taken from the authentication procedure). > there you can simply split the domain part from the user part. > > however, geopriv tries to support different 'using protocols'. one possible > using protocol is sip but there are many others. > > these using protocols typically have different authentication mechanisms > which again use different identities. identities in http digest, x.509 > certificates, kerberos principal names etc. have a different structure. you > need to know the structure in order to extract the domain part. > > without your approach you don't need to understand the structure of > the identifier. you only do an equality match. > > ciao > hannes > > >>>hi jonathan, >>> >>>could you describe how the domain authorization procedure works? >>>where do you get the domain part for the identifier. the problem we >>>saw in the past was that you have to understand the structure of >>>the identifier in order for it to work. >> >>I'm not sure I follow. I work for dynamicsoft.com. All URIs in my >>domain are user@dynamicsoft.com. I'd like a policy which >>allows anyone >>in dynamicsoft.com, but blocks a few irritating people, say joe and >>bob. So, I would have a policy like this: >> >> >> dynamicsoft.com >> >> joe@dynamicsoft.com >> bob@dynamicsoft.com >> >> >> >> >>Where is the complexity here? >> >> >> >>>ciao hannes >>> >>>btw, another small issue. the name of the authorization draft is >>>very misleading. there is no need to contain the name xcap in there >>>since the policies should actually be independent of xcap. i >>>noticed the problem with the names in various discussions. people >>>automatically think that those two belong together. >> >>Yes, I realize that - others have commented similarly. I will >>be happy >>to split it up into pieces, wth the XML schema separately, once we >>have a better grasp of how to bring these two works together. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 15:02:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04282 for ; Fri, 7 Nov 2003 15:02:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICo6-0004WQ-Ln for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 15:02:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7K2ARt017376 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 15:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICo6-0004WB-I9 for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:02:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04238; Fri, 7 Nov 2003 15:01:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICo2-0002DJ-00; Fri, 07 Nov 2003 15:02:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICo1-0002DG-00; Fri, 07 Nov 2003 15:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICnx-0004T8-Pw; Fri, 07 Nov 2003 15:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICnn-0004SX-Br for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04229; Fri, 7 Nov 2003 15:01:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICnj-0002D0-00; Fri, 07 Nov 2003 15:01:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AICnj-0002Cx-00; Fri, 07 Nov 2003 15:01:47 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7K0wca013652; Fri, 7 Nov 2003 15:00:58 -0500 (EST) Message-ID: <3FABF9F8.6050400@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC0406@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0406@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:00:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sure, not every identity system supports the notions of a user and a domain, but a LOT of them do. In any one system in which geopriv gets used, you will have to know the set of identity types that are in use. Any one system will support only a finite number of authentication systems, each of which only supports some number of identities. Even if you assume an authentication system that can support any type of identity, the geopriv processing would seem to require you to understand the type of identity, in order to perform an equality operation on it. As such, I dont see the issue in allowing geopriv to support domain based identifiers. If a user is authenticated with a particular identity that doesnt have the concept of a domain, that user wouldn't be a match for any of operations. -Jonathan R. Tschofenig Hannes wrote: > hi jonathan, > > the problem with your approach is the following: you are simply assuming an > email type of identity (which is taken from the authentication procedure). > there you can simply split the domain part from the user part. > > however, geopriv tries to support different 'using protocols'. one possible > using protocol is sip but there are many others. > > these using protocols typically have different authentication mechanisms > which again use different identities. identities in http digest, x.509 > certificates, kerberos principal names etc. have a different structure. you > need to know the structure in order to extract the domain part. > > without your approach you don't need to understand the structure of > the identifier. you only do an equality match. > > ciao > hannes > > >>>hi jonathan, >>> >>>could you describe how the domain authorization procedure works? >>>where do you get the domain part for the identifier. the problem we >>>saw in the past was that you have to understand the structure of >>>the identifier in order for it to work. >> >>I'm not sure I follow. I work for dynamicsoft.com. All URIs in my >>domain are user@dynamicsoft.com. I'd like a policy which >>allows anyone >>in dynamicsoft.com, but blocks a few irritating people, say joe and >>bob. So, I would have a policy like this: >> >> >> dynamicsoft.com >> >> joe@dynamicsoft.com >> bob@dynamicsoft.com >> >> >> >> >>Where is the complexity here? >> >> >> >>>ciao hannes >>> >>>btw, another small issue. the name of the authorization draft is >>>very misleading. there is no need to contain the name xcap in there >>>since the policies should actually be independent of xcap. i >>>noticed the problem with the names in various discussions. people >>>automatically think that those two belong together. >> >>Yes, I realize that - others have commented similarly. I will >>be happy >>to split it up into pieces, wth the XML schema separately, once we >>have a better grasp of how to bring these two works together. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 15:04:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04368; Fri, 7 Nov 2003 15:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICq2-0002F1-00; Fri, 07 Nov 2003 15:04:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICq2-0002Ey-00; Fri, 07 Nov 2003 15:04:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICpt-0004b7-QV; Fri, 07 Nov 2003 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICp2-0004ZG-VW for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:03:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04313; Fri, 7 Nov 2003 15:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICoz-0002E3-00; Fri, 07 Nov 2003 15:03:05 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AICoy-0002De-00; Fri, 07 Nov 2003 15:03:04 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7K2Kca013658; Fri, 7 Nov 2003 15:02:20 -0500 (EST) Message-ID: <3FABFA4A.4070402@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: Tschofenig Hannes , Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FABA9FA.6010008@ecotroph.net> In-Reply-To: <3FABA9FA.6010008@ecotroph.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:02:18 -0500 Content-Transfer-Encoding: 7bit inline. Andrew Newton wrote: > Jonathan Rosenberg wrote: > >> >> >> dynamicsoft.com >> >> joe@dynamicsoft.com >> bob@dynamicsoft.com >> >> >> >> >> Where is the complexity here? > > > What is wrong with using group roles with the syntax specified in the > draft? Such as: > > > mailto:support-staff@example.com > ... > > > -andy > Assuming a user can authenticate themselves as "mailto:support-staff@example.com", the fact that this is a group identity would be irrelevant to the system. As such, it would be supported in the sense that it didnt matter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 15:04:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04429 for ; Fri, 7 Nov 2003 15:04:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICq7-0004fU-4a for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 15:04:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7K4Fdm017938 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 15:04:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICq7-0004fF-1H for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:04:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04368; Fri, 7 Nov 2003 15:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICq2-0002F1-00; Fri, 07 Nov 2003 15:04:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AICq2-0002Ey-00; Fri, 07 Nov 2003 15:04:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICpt-0004b7-QV; Fri, 07 Nov 2003 15:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICp2-0004ZG-VW for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:03:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04313; Fri, 7 Nov 2003 15:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICoz-0002E3-00; Fri, 07 Nov 2003 15:03:05 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AICoy-0002De-00; Fri, 07 Nov 2003 15:03:04 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7K2Kca013658; Fri, 7 Nov 2003 15:02:20 -0500 (EST) Message-ID: <3FABFA4A.4070402@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: Tschofenig Hannes , Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FABA9FA.6010008@ecotroph.net> In-Reply-To: <3FABA9FA.6010008@ecotroph.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:02:18 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Andrew Newton wrote: > Jonathan Rosenberg wrote: > >> >> >> dynamicsoft.com >> >> joe@dynamicsoft.com >> bob@dynamicsoft.com >> >> >> >> >> Where is the complexity here? > > > What is wrong with using group roles with the syntax specified in the > draft? Such as: > > > mailto:support-staff@example.com > ... > > > -andy > Assuming a user can authenticate themselves as "mailto:support-staff@example.com", the fact that this is a group identity would be irrelevant to the system. As such, it would be supported in the sense that it didnt matter. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 15:22:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05898; Fri, 7 Nov 2003 15:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AID8M-0002Q6-00; Fri, 07 Nov 2003 15:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AID8L-0002Q0-00; Fri, 07 Nov 2003 15:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID8I-0005Wy-0R; Fri, 07 Nov 2003 15:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID7w-0005Vc-RW for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:22:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05816; Fri, 7 Nov 2003 15:22:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AID7u-0002Pb-00; Fri, 07 Nov 2003 15:22:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AID7u-0002PF-00; Fri, 07 Nov 2003 15:22:38 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7KLaca013666; Fri, 7 Nov 2003 15:21:36 -0500 (EST) Message-ID: <3FABFECE.4040606@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> In-Reply-To: <3FABB2B9.3060003@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:21:34 -0500 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >>> I don't understand why the except clause in each permission >>> statement should be dismissed while the separate exception list >>> model can be supported. > > > The exception list is restricted in its functionality to avoid the > privacy problems caused by exception entries. Mixing the two means > that both list types would need to be restricted as described. > > Also, having unbounded except lists makes processing more > complicated since the simple row model no longer applies (it's no > longer a relational table). I share Ito-san's confusion here. Assuming the same kind of restrictions you have asked for - no external references, no wildcards, no domain-scopes, I dont see the difference between: example.com joe@example.com and: example.com joe@example.com THe differences seem merely syntactic, but maybe I am missing something here. Henning also wrote: > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd > hate to create a complicated, brittle, difficult-to-predict system > just to find out a year later that this expensive feature turned > out to be mostly an empty promise, in terms of increasing user > privacy. There are some serious differences here with the email spam case. Firstly, the systems we are talking about require authentication, which is absent in email. Secondly, and perhaps most importantly, I am not interested in rules like "allow anyone in the world but bob@example.com", as I agree this is silly. We are talking about rules like "allow only people from example.com EXCEPT bob@example.com". That is, I expect these systems to require a user to explicitly grant a permission, but an extremely common case, I think, will be to grant it by indicating a domain with a set of exceptions. Ted wrote: > To take up your point on implementation, I note that > folks do seem to be assuming a connection between > the UI and the protocol behavior. I can easily see > a UI saying "Grant all buddies civil geolocation data > at City level, except $ex-spouse, who should get > my timezone" and translating that as a grant of > timezone to all buddies and a second grant of > City to each of those that isn't the ex-spouse. From > the user point of view, it's an "except", where from the > protocol point of view it is additive permissions. > > There is no question that there are engineering trade-offs here. > You gain simplicity and have an easy method to > ensure maximal privacy, but you may get increased > object size and you may need to structure group data > in ways that ensure it fits this model reasonably > efficiently. Neither choice is perfect, but this one > does have some very useful characteristics for a > large number of GeoPriv cases. There may be other > usage patterns in other uses of XCAP that mean > we can't have a perfect fit, but if we can keep that > split to a minimum, I think it's worth it. To summarize (correct me if I am wrong), I think your suggestion was that exceptions can be handled by expanding the lists associated with the domain. As such, even though the user sees an exception rule in the UI, the underlying system pushes a permission with everyone in it. My concern is that I believe this will be very difficult to manage. It requires the users to have access to the set of users in the domain from which the exceptions are being specified. That list is undoubtedly dynamic, and potentially pretty large. When a new employee joins the company, everyone would have to update their permissiosn (or have their agents do it automatically somehow), and similarly when someone leaves. The result will be odd behavior for users, where people that a user believes to have permission, actually doesnt. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 15:23:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05989 for ; Fri, 7 Nov 2003 15:23:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID8P-0005Zl-Am for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 15:23:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7KN9hw021432 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 15:23:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID8P-0005Zb-7R for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05898; Fri, 7 Nov 2003 15:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AID8M-0002Q6-00; Fri, 07 Nov 2003 15:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AID8L-0002Q0-00; Fri, 07 Nov 2003 15:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID8I-0005Wy-0R; Fri, 07 Nov 2003 15:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AID7w-0005Vc-RW for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:22:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05816; Fri, 7 Nov 2003 15:22:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AID7u-0002Pb-00; Fri, 07 Nov 2003 15:22:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AID7u-0002PF-00; Fri, 07 Nov 2003 15:22:38 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7KLaca013666; Fri, 7 Nov 2003 15:21:36 -0500 (EST) Message-ID: <3FABFECE.4040606@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> In-Reply-To: <3FABB2B9.3060003@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:21:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >>> I don't understand why the except clause in each permission >>> statement should be dismissed while the separate exception list >>> model can be supported. > > > The exception list is restricted in its functionality to avoid the > privacy problems caused by exception entries. Mixing the two means > that both list types would need to be restricted as described. > > Also, having unbounded except lists makes processing more > complicated since the simple row model no longer applies (it's no > longer a relational table). I share Ito-san's confusion here. Assuming the same kind of restrictions you have asked for - no external references, no wildcards, no domain-scopes, I dont see the difference between: example.com joe@example.com and: example.com joe@example.com THe differences seem merely syntactic, but maybe I am missing something here. Henning also wrote: > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd > hate to create a complicated, brittle, difficult-to-predict system > just to find out a year later that this expensive feature turned > out to be mostly an empty promise, in terms of increasing user > privacy. There are some serious differences here with the email spam case. Firstly, the systems we are talking about require authentication, which is absent in email. Secondly, and perhaps most importantly, I am not interested in rules like "allow anyone in the world but bob@example.com", as I agree this is silly. We are talking about rules like "allow only people from example.com EXCEPT bob@example.com". That is, I expect these systems to require a user to explicitly grant a permission, but an extremely common case, I think, will be to grant it by indicating a domain with a set of exceptions. Ted wrote: > To take up your point on implementation, I note that > folks do seem to be assuming a connection between > the UI and the protocol behavior. I can easily see > a UI saying "Grant all buddies civil geolocation data > at City level, except $ex-spouse, who should get > my timezone" and translating that as a grant of > timezone to all buddies and a second grant of > City to each of those that isn't the ex-spouse. From > the user point of view, it's an "except", where from the > protocol point of view it is additive permissions. > > There is no question that there are engineering trade-offs here. > You gain simplicity and have an easy method to > ensure maximal privacy, but you may get increased > object size and you may need to structure group data > in ways that ensure it fits this model reasonably > efficiently. Neither choice is perfect, but this one > does have some very useful characteristics for a > large number of GeoPriv cases. There may be other > usage patterns in other uses of XCAP that mean > we can't have a perfect fit, but if we can keep that > split to a minimum, I think it's worth it. To summarize (correct me if I am wrong), I think your suggestion was that exceptions can be handled by expanding the lists associated with the domain. As such, even though the user sees an exception rule in the UI, the underlying system pushes a permission with everyone in it. My concern is that I believe this will be very difficult to manage. It requires the users to have access to the set of users in the domain from which the exceptions are being specified. That list is undoubtedly dynamic, and potentially pretty large. When a new employee joins the company, everyone would have to update their permissiosn (or have their agents do it automatically somehow), and similarly when someone leaves. The result will be odd behavior for users, where people that a user believes to have permission, actually doesnt. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 15:30:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06446; Fri, 7 Nov 2003 15:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDG3-0002YF-00; Fri, 07 Nov 2003 15:31:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDG3-0002YC-00; Fri, 07 Nov 2003 15:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDG2-0005wH-7q; Fri, 07 Nov 2003 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDFX-0005uu-Tn for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:30:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06431; Fri, 7 Nov 2003 15:30:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDFW-0002Xr-00; Fri, 07 Nov 2003 15:30:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIDFV-0002W9-00; Fri, 07 Nov 2003 15:30:29 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7KU0ca013696; Fri, 7 Nov 2003 15:30:00 -0500 (EST) Message-ID: <3FAC00C6.7020001@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> In-Reply-To: <3FABA901.4040006@ecotroph.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:29:58 -0500 Content-Transfer-Encoding: 7bit Andrew Newton wrote: > As I recall: at the interim meeting in September we were fortunate to > have two people in attendance that had implemented similar access > systems. It was their opinion that the 'except' clause adds enough > processing to be a scalability concern for even moderately loaded > systems. The fastest systems are able to take a set of rules and > process them one after another until there is a hit. For how many users? For how many rules? On what kind of processor? On what kind of OS? With what kind of programming language? With what kind of database? I don't buy the argument "it doesnt scale" in the absence of a concrete definition about the system in which this conclusion was drawn. In the systems I am interested in, I see a user as having maybe 50-60 users to whom explicit permissions are granted, and 1-2 domains. Within each domain, there would be one or two users that are excepted from the domain. In such a system of this size, I see no real scalability issues. An easy implementation of this would do a table lookup of the watcher in a uri table, and do a lookup in a domain table. If there is a matchi n the domain table, and the "exceptions" flag is set (meaning exceptions are present), I do another lookup in the exceptions table based on the uri. As such, we are talking about 2 table lookups vs. 3, in addition to any other kind of processing going on (such as alteration of the granularity of location data), which I expect to be computationally more expensive than a table lookup. I can also think of optimizations which combine the two uri lookups into a single table lookup. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 15:31:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06489 for ; Fri, 7 Nov 2003 15:31:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDG6-0005z6-1K for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 15:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7KV5CE022998 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 15:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDG5-0005yr-Tv for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 15:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06446; Fri, 7 Nov 2003 15:30:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDG3-0002YF-00; Fri, 07 Nov 2003 15:31:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDG3-0002YC-00; Fri, 07 Nov 2003 15:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDG2-0005wH-7q; Fri, 07 Nov 2003 15:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDFX-0005uu-Tn for simple@optimus.ietf.org; Fri, 07 Nov 2003 15:30:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06431; Fri, 7 Nov 2003 15:30:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDFW-0002Xr-00; Fri, 07 Nov 2003 15:30:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIDFV-0002W9-00; Fri, 07 Nov 2003 15:30:29 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7KU0ca013696; Fri, 7 Nov 2003 15:30:00 -0500 (EST) Message-ID: <3FAC00C6.7020001@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Newton CC: Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> In-Reply-To: <3FABA901.4040006@ecotroph.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:29:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andrew Newton wrote: > As I recall: at the interim meeting in September we were fortunate to > have two people in attendance that had implemented similar access > systems. It was their opinion that the 'except' clause adds enough > processing to be a scalability concern for even moderately loaded > systems. The fastest systems are able to take a set of rules and > process them one after another until there is a hit. For how many users? For how many rules? On what kind of processor? On what kind of OS? With what kind of programming language? With what kind of database? I don't buy the argument "it doesnt scale" in the absence of a concrete definition about the system in which this conclusion was drawn. In the systems I am interested in, I see a user as having maybe 50-60 users to whom explicit permissions are granted, and 1-2 domains. Within each domain, there would be one or two users that are excepted from the domain. In such a system of this size, I see no real scalability issues. An easy implementation of this would do a table lookup of the watcher in a uri table, and do a lookup in a domain table. If there is a matchi n the domain table, and the "exceptions" flag is set (meaning exceptions are present), I do another lookup in the exceptions table based on the uri. As such, we are talking about 2 table lookups vs. 3, in addition to any other kind of processing going on (such as alteration of the granularity of location data), which I expect to be computationally more expensive than a table lookup. I can also think of optimizations which combine the two uri lookups into a single table lookup. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 16:10:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07593; Fri, 7 Nov 2003 16:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDrw-0002wM-00; Fri, 07 Nov 2003 16:10:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDrw-0002wJ-00; Fri, 07 Nov 2003 16:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDrm-0008Uh-9M; Fri, 07 Nov 2003 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDrd-0008Tz-K0 for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:09:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07581; Fri, 7 Nov 2003 16:09:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDra-0002vz-00; Fri, 07 Nov 2003 16:09:50 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AIDrZ-0002vk-00; Fri, 07 Nov 2003 16:09:49 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hA7L8lcb007448; Fri, 7 Nov 2003 15:08:47 -0600 (CST) Message-ID: <3FAC09DC.496B33B4@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: hardie@qualcomm.com, Jonathan Rosenberg , Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:08:44 -0600 Content-Transfer-Encoding: 7bit All this is not too clear to me yet, but an exception can be viewed simply as a form negative addition. Therefore it theoretically shouldn't violate the "additive permissions theory". The idea of a black list works fine in an enterprise type environment. I think I see value in it. Regards, Alex. Henning Schulzrinne wrote: > If there is consensus that we really can't avoid exceptions, I would > suggest a variation of Ted's approach, namely to have a clear, separate > exceptions list: > > - First, consult the exceptions list. If there's a match in the > exceptions list, there is no need to consult the second list. If the LS > or PA can't access the exceptions list, the system delivers no > information and fails hard for that delivery destination. The exception > list permits no inclusions, no all-within-domain wildcards and no > external references. (Permissions within the exceptions list are still > additive.) > > - If no match, consult the normal additive-privileges list, with no > exceptions. > > This supports the all-20,000-Columbia-employees except Alice and Bob, > but does not support Columbia-except-the-EE-department. > > This has the advantage that the row-model is maintained, rather than > having lists of exceptions attached to each rule. > > GEOPRIV might then decide not to support the exception list type, but > the regular list type would be compatible. > > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd hate to > create a complicated, brittle, difficult-to-predict system just to find > out a year later that this expensive feature turned out to be mostly an > empty promise, in terms of increasing user privacy. > > Note that I'm not advocating the solution - I'd rather not add the > complexity and I'm not sure whether I have caught all the possible > failure cases. > > It would be helpful if others would speak up, as this is an important > issue to settle, soon. > > hardie@qualcomm.com wrote: > > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > > > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > >> > >> > >> dynamicsoft.com > >> > >> joe@dynamicsoft.com > >> bob@dynamicsoft.com > >> > >> > >> > >>Where is the complexity here? > > > > > > > > The complexity here from the GeoPriv side is really in how additive permissions are > > meant to work. In order to ensure that the privacy policy is always within the > > user's tolerance, the theory has been to have a very small set of "grants" that > > are then always modified by addition. If the URI at which a specific addition > > is made is not available (or the object in which it is contained is not decryptable), > > then the results may be less than optimal, but there are no untoward > > privacy consequences, as there can never be a "grant statement" that takes > > something away. We talked about "except" in particular at the interim meeting > > and, from my memory, we had good agreement that "except" was powerful, > > interesting, but conflicted enough with the core theory and the needed functionality > > that it wouldn't be a phase one. > > > > Could I suggest that we consider splitting into two, one of which > > has except and one does not? We could have and . > > The first would be the basic grant: > > > > example.com > > > > where the second would allow: > > > > example.com > > joe@example.com. > > > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > > GEOPRIV, but allow GeoPriv to punt implementation of until > > a later time when it has worked out more of the surrounding infrastructure. It is > > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > > this looks like the most direct way to hack past the problem without losing > > the basic overlap. > > regards, > > Ted Hardie > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 7 16:10:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07639 for ; Fri, 7 Nov 2003 16:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDrz-0008Vu-Le for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 16:10:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LAF0p032720 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 16:10:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDrz-0008Vf-HG for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:10:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07593; Fri, 7 Nov 2003 16:10:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDrw-0002wM-00; Fri, 07 Nov 2003 16:10:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDrw-0002wJ-00; Fri, 07 Nov 2003 16:10:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDrm-0008Uh-9M; Fri, 07 Nov 2003 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDrd-0008Tz-K0 for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:09:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07581; Fri, 7 Nov 2003 16:09:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDra-0002vz-00; Fri, 07 Nov 2003 16:09:50 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AIDrZ-0002vk-00; Fri, 07 Nov 2003 16:09:49 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hA7L8lcb007448; Fri, 7 Nov 2003 15:08:47 -0600 (CST) Message-ID: <3FAC09DC.496B33B4@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: hardie@qualcomm.com, Jonathan Rosenberg , Tschofenig Hannes , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:08:44 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit All this is not too clear to me yet, but an exception can be viewed simply as a form negative addition. Therefore it theoretically shouldn't violate the "additive permissions theory". The idea of a black list works fine in an enterprise type environment. I think I see value in it. Regards, Alex. Henning Schulzrinne wrote: > If there is consensus that we really can't avoid exceptions, I would > suggest a variation of Ted's approach, namely to have a clear, separate > exceptions list: > > - First, consult the exceptions list. If there's a match in the > exceptions list, there is no need to consult the second list. If the LS > or PA can't access the exceptions list, the system delivers no > information and fails hard for that delivery destination. The exception > list permits no inclusions, no all-within-domain wildcards and no > external references. (Permissions within the exceptions list are still > additive.) > > - If no match, consult the normal additive-privileges list, with no > exceptions. > > This supports the all-20,000-Columbia-employees except Alice and Bob, > but does not support Columbia-except-the-EE-department. > > This has the advantage that the row-model is maintained, rather than > having lists of exceptions attached to each rule. > > GEOPRIV might then decide not to support the exception list type, but > the regular list type would be compatible. > > Blacklists were popular for spam-protection early on, but I think > everyone has realized by now that they are close to useless. I'd hate to > create a complicated, brittle, difficult-to-predict system just to find > out a year later that this expensive feature turned out to be mostly an > empty promise, in terms of increasing user privacy. > > Note that I'm not advocating the solution - I'd rather not add the > complexity and I'm not sure whether I have caught all the possible > failure cases. > > It would be helpful if others would speak up, as this is an important > issue to settle, soon. > > hardie@qualcomm.com wrote: > > At 2:07 PM -0500 11/06/2003, Jonathan Rosenberg wrote: > > > >>not sure I follow. I work for dynamicsoft.com. All URIs in my domain are user@dynamicsoft.com. I'd like a policy which allows anyone in dynamicsoft.com, but blocks a few irritating people, say joe and bob. So, I would have a policy like this: > >> > >> > >> dynamicsoft.com > >> > >> joe@dynamicsoft.com > >> bob@dynamicsoft.com > >> > >> > >> > >>Where is the complexity here? > > > > > > > > The complexity here from the GeoPriv side is really in how additive permissions are > > meant to work. In order to ensure that the privacy policy is always within the > > user's tolerance, the theory has been to have a very small set of "grants" that > > are then always modified by addition. If the URI at which a specific addition > > is made is not available (or the object in which it is contained is not decryptable), > > then the results may be less than optimal, but there are no untoward > > privacy consequences, as there can never be a "grant statement" that takes > > something away. We talked about "except" in particular at the interim meeting > > and, from my memory, we had good agreement that "except" was powerful, > > interesting, but conflicted enough with the core theory and the needed functionality > > that it wouldn't be a phase one. > > > > Could I suggest that we consider splitting into two, one of which > > has except and one does not? We could have and . > > The first would be the basic grant: > > > > example.com > > > > where the second would allow: > > > > example.com > > joe@example.com. > > > > I think that would enable us to overlap a lot of the xcap language between SIMPLE and > > GEOPRIV, but allow GeoPriv to punt implementation of until > > a later time when it has worked out more of the surrounding infrastructure. It is > > inelegant, I know, but GeoPriv is now working under pretty heavy time pressure, and > > this looks like the most direct way to hack past the problem without losing > > the basic overlap. > > regards, > > Ted Hardie > > _______________________________________________ > 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-admin@ietf.org Fri Nov 7 16:10:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07660; Fri, 7 Nov 2003 16:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDsm-0002xS-00; Fri, 07 Nov 2003 16:11:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDsm-0002xP-00; Fri, 07 Nov 2003 16:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDsk-000093-MT; Fri, 07 Nov 2003 16:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDsR-00007e-Ee for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07637; Fri, 7 Nov 2003 16:10:31 -0500 (EST) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDsP-0002xA-00; Fri, 07 Nov 2003 16:10:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AIDsO-0002x7-00; Fri, 07 Nov 2003 16:10:40 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7LAV4t025854; Fri, 7 Nov 2003 13:10:31 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7LAS0O004233; Fri, 7 Nov 2003 13:10:29 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3FABFECE.4040606@dynamicsoft.com> References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> To: Jonathan Rosenberg , Henning Schulzrinne Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth Cc: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 13:10:30 -0800 At 3:21 PM -0500 11/07/2003, Jonathan Rosenberg wrote: > >To summarize (correct me if I am wrong), I think your suggestion was that exceptions can be handled by expanding the lists associated with the domain. As such, even though the user sees an exception rule in the UI, the underlying system pushes a permission with everyone in it. I'm saying that's the protocol's view of the permission and the structure in which they're encoded and sent. How the underlying system store the permissions is, I think, a local optimization. >My concern is that I believe this will be very difficult to manage. It requires the users to have access to the set of users in the domain from which the exceptions are being specified. That list is undoubtedly dynamic, and potentially pretty large. When a new employee joins the company, everyone would have to update their permissiosn (or have their agents do it automatically somehow), and similarly when someone leaves. The result will be odd behavior for users, where people that a user believes to have permission, actually doesnt. > This gets one of the points I was trying to make earlier; the difficulty here depends on how the group data is structured. Let's assume that we have a very wide, flat identifier, like "user@qualcomm.com"; granting to domain "qualcomm.com" with an except on the basis of that identifier would be tough. If the identifiers were not email-like, though, but based on group identifiers that were more distributed, then granting them is slightly more tedious, but the except clauses become easier--as it is a flat grant to groups 1-100, and increased grant to groups 1-9 and 11-100, an increased grant to member 1,3,4 of group 10, and a failure to grant to member 2 of group 10. This does mean that adding to member 5 to group 10 creates a synchronization problem. There are ways around that, and they are tedious and potentially flakey. You don't need to use them, though, unless you are doing exception based processing. If this is very common, we may need to change our view of what is critical. In the short term, I believe that getting to the point where the user can grant permissions on a "domain" (not necessarily DNS label) is considerably beyond where we are today, and I think a lot of the real need in GeoPriv is handled by the explicit grant case. Doing exception based processing might be possible, but it seems to put a burden on the processor that requires it to ensure it has processed *all rules* before it can proceed (perhaps a better way to put this is that it has processed all "includes" before it can proceed). If it does not process all rules, there seems to be a not trivial risk that user@qualcomm.com (a.k.a. Member 2 of group 10) gets data that the privacy policy doesn't allow. That's simple not okay in the GeoPriv view of the world. I hope this is at least somewhat more clear, and I look forward to continuing the discussion when we can scribble on a whiteboard/piece of paper. regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 16:11:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07730 for ; Fri, 7 Nov 2003 16:11:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDsq-0000Cb-Br for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 16:11:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LB8XS000771 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 16:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDsq-0000CM-6L for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07660; Fri, 7 Nov 2003 16:10:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDsm-0002xS-00; Fri, 07 Nov 2003 16:11:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIDsm-0002xP-00; Fri, 07 Nov 2003 16:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDsk-000093-MT; Fri, 07 Nov 2003 16:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIDsR-00007e-Ee for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:10:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07637; Fri, 7 Nov 2003 16:10:31 -0500 (EST) From: hardie@qualcomm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIDsP-0002xA-00; Fri, 07 Nov 2003 16:10:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AIDsO-0002x7-00; Fri, 07 Nov 2003 16:10:40 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7LAV4t025854; Fri, 7 Nov 2003 13:10:31 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hA7LAS0O004233; Fri, 7 Nov 2003 13:10:29 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <3FABFECE.4040606@dynamicsoft.com> References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> To: Jonathan Rosenberg , Henning Schulzrinne Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth Cc: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 7 Nov 2003 13:10:30 -0800 At 3:21 PM -0500 11/07/2003, Jonathan Rosenberg wrote: > >To summarize (correct me if I am wrong), I think your suggestion was that exceptions can be handled by expanding the lists associated with the domain. As such, even though the user sees an exception rule in the UI, the underlying system pushes a permission with everyone in it. I'm saying that's the protocol's view of the permission and the structure in which they're encoded and sent. How the underlying system store the permissions is, I think, a local optimization. >My concern is that I believe this will be very difficult to manage. It requires the users to have access to the set of users in the domain from which the exceptions are being specified. That list is undoubtedly dynamic, and potentially pretty large. When a new employee joins the company, everyone would have to update their permissiosn (or have their agents do it automatically somehow), and similarly when someone leaves. The result will be odd behavior for users, where people that a user believes to have permission, actually doesnt. > This gets one of the points I was trying to make earlier; the difficulty here depends on how the group data is structured. Let's assume that we have a very wide, flat identifier, like "user@qualcomm.com"; granting to domain "qualcomm.com" with an except on the basis of that identifier would be tough. If the identifiers were not email-like, though, but based on group identifiers that were more distributed, then granting them is slightly more tedious, but the except clauses become easier--as it is a flat grant to groups 1-100, and increased grant to groups 1-9 and 11-100, an increased grant to member 1,3,4 of group 10, and a failure to grant to member 2 of group 10. This does mean that adding to member 5 to group 10 creates a synchronization problem. There are ways around that, and they are tedious and potentially flakey. You don't need to use them, though, unless you are doing exception based processing. If this is very common, we may need to change our view of what is critical. In the short term, I believe that getting to the point where the user can grant permissions on a "domain" (not necessarily DNS label) is considerably beyond where we are today, and I think a lot of the real need in GeoPriv is handled by the explicit grant case. Doing exception based processing might be possible, but it seems to put a burden on the processor that requires it to ensure it has processed *all rules* before it can proceed (perhaps a better way to put this is that it has processed all "includes" before it can proceed). If it does not process all rules, there seems to be a not trivial risk that user@qualcomm.com (a.k.a. Member 2 of group 10) gets data that the privacy policy doesn't allow. That's simple not okay in the GeoPriv view of the world. I hope this is at least somewhat more clear, and I look forward to continuing the discussion when we can scribble on a whiteboard/piece of paper. regards, Ted _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 16:21:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08202; Fri, 7 Nov 2003 16:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2X-00039j-00; Fri, 07 Nov 2003 16:21:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2X-00039g-00; Fri, 07 Nov 2003 16:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2R-0001QO-UP; Fri, 07 Nov 2003 16:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1z-0001LG-Ow for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:20:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08144 for ; Fri, 7 Nov 2003 16:20:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1x-00038Y-00 for simple@ietf.org; Fri, 07 Nov 2003 16:20:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AIE1w-00038V-00 for simple@ietf.org; Fri, 07 Nov 2003 16:20:33 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7LJSIc029777; Fri, 7 Nov 2003 15:19:35 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAC0C55.3070806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94CC0.4070709@cisco.com> In-Reply-To: <3FA94CC0.4070709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:19:17 -0600 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > > These are really good questions, worth a separate thread. > >> - Section 6.3: >> - the BNF provided allows accept-types to have multiple *. eg: >> a=accept-types: * * * >> It should be fixed to something like: >> accept-types = accept-types-label ":" format-list >> accept-types-label = "accept-types" >> format-list = "*" / format-entries >> format-entries = format-entry *( SP format-entry) >> format-entry = (type "/" subtype) >> type = token >> subtype = token > > > I thought we were changing to having *only* a "*" on the m-line and > doing all the rest with attributes. > Hisham was not referring to the m-line. The BNF above refers to the accept-types attribute. [...] > > Another one that deserves its own topic. > >> - Section 7.4.4: >> - an INVITE request can also terminate a message session (port 0). >> That should be noted along side the SIP BYE example. Otherwise >> implementers will think that only a BYE can terminate a message session. > > > Yes. And UPDATE is yet another way to accomplish this. > As I mentioned in a separate post, I think a throrough set of use cases would be useful. But do they belong in this document, or a separate one? Since this doc is not supposed to be normatively tied to SIP, it may make more sense to separate them. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 16:21:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08328 for ; Fri, 7 Nov 2003 16:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2b-0001Yn-3m for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 16:21:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LLD9q005991 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 16:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2b-0001YY-04 for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:21:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08202; Fri, 7 Nov 2003 16:21:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE2X-00039j-00; Fri, 07 Nov 2003 16:21:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE2X-00039g-00; Fri, 07 Nov 2003 16:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE2R-0001QO-UP; Fri, 07 Nov 2003 16:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE1z-0001LG-Ow for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:20:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08144 for ; Fri, 7 Nov 2003 16:20:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE1x-00038Y-00 for simple@ietf.org; Fri, 07 Nov 2003 16:20:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AIE1w-00038V-00 for simple@ietf.org; Fri, 07 Nov 2003 16:20:33 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7LJSIc029777; Fri, 7 Nov 2003 15:19:35 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAC0C55.3070806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94CC0.4070709@cisco.com> In-Reply-To: <3FA94CC0.4070709@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:19:17 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > > These are really good questions, worth a separate thread. > >> - Section 6.3: >> - the BNF provided allows accept-types to have multiple *. eg: >> a=accept-types: * * * >> It should be fixed to something like: >> accept-types = accept-types-label ":" format-list >> accept-types-label = "accept-types" >> format-list = "*" / format-entries >> format-entries = format-entry *( SP format-entry) >> format-entry = (type "/" subtype) >> type = token >> subtype = token > > > I thought we were changing to having *only* a "*" on the m-line and > doing all the rest with attributes. > Hisham was not referring to the m-line. The BNF above refers to the accept-types attribute. [...] > > Another one that deserves its own topic. > >> - Section 7.4.4: >> - an INVITE request can also terminate a message session (port 0). >> That should be noted along side the SIP BYE example. Otherwise >> implementers will think that only a BYE can terminate a message session. > > > Yes. And UPDATE is yet another way to accomplish this. > As I mentioned in a separate post, I think a throrough set of use cases would be useful. But do they belong in this document, or a separate one? Since this doc is not supposed to be normatively tied to SIP, it may make more sense to separate them. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 16:23:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08397; Fri, 7 Nov 2003 16:23:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE5P-0003Bw-00; Fri, 07 Nov 2003 16:24:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE5O-0003Bp-00; Fri, 07 Nov 2003 16:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE5J-00022T-De; Fri, 07 Nov 2003 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE4R-0001yU-N2 for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:23:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08377 for ; Fri, 7 Nov 2003 16:22:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE4P-0003BA-00 for simple@ietf.org; Fri, 07 Nov 2003 16:23:05 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AIE4O-0003B7-00 for simple@ietf.org; Fri, 07 Nov 2003 16:23:04 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7LMvIc030022; Fri, 7 Nov 2003 15:22:58 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAC0D26.4070402@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> In-Reply-To: <3FA94DC6.7020400@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:22:46 -0600 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > hisham.khartabil@nokia.com wrote: > >> >> - Section 7.4.3: >> - In step 5 "The endpoint MAY attempt to send the message content >> again" > > > Should we remove this text? If the message sending fails, so be it. > > The user can choose to send it again. This avoids the very large > message > > being sent again (long messages have the potential to falsely > timing out > > and the sender gets a 500 response). > > I agree this should go. We may want to discuss possibility of > establishing a replacement media session and then retrying the message > there. In that case I think we perhaps should make it permissible for > the retry to use the same TR-ID. It is then optional whether the > recipient detects the duplicate or not. I don't mind mentioning that some implementations might choose to create a new session and attempt to resume a conversation--but I do not want to imply that it should or should not be done. As far as retrying the same TR-ID, I do not think that is useful unless we strengthen the uniqueness requirements for TR-ID, and recommend some period of time that an endpoint should remember previous ones it had seen. > > This addresses the case where a relay crashes in an ungraceful way. > >> - Open issue: NO. > > > I guess what I am proposing is YES, but with a weak mechanism - neither > side is *required* to enable duplicate suppression, but the mechanism is > there if both sides choose to use it. > I assume the weak mechanism to which you refer is the TR-ID approach mentioned above. See my comments above. > Paul > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 7 16:24:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08422 for ; Fri, 7 Nov 2003 16:24:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE5S-00026U-Tm for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 16:24:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LOAhR008080 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 16:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE5S-00026F-QY for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08397; Fri, 7 Nov 2003 16:23:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE5P-0003Bw-00; Fri, 07 Nov 2003 16:24:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIE5O-0003Bp-00; Fri, 07 Nov 2003 16:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE5J-00022T-De; Fri, 07 Nov 2003 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE4R-0001yU-N2 for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:23:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08377 for ; Fri, 7 Nov 2003 16:22:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE4P-0003BA-00 for simple@ietf.org; Fri, 07 Nov 2003 16:23:05 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AIE4O-0003B7-00 for simple@ietf.org; Fri, 07 Nov 2003 16:23:04 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA7LMvIc030022; Fri, 7 Nov 2003 15:22:58 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAC0D26.4070402@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> In-Reply-To: <3FA94DC6.7020400@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 15:22:46 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > hisham.khartabil@nokia.com wrote: > >> >> - Section 7.4.3: >> - In step 5 "The endpoint MAY attempt to send the message content >> again" > > > Should we remove this text? If the message sending fails, so be it. > > The user can choose to send it again. This avoids the very large > message > > being sent again (long messages have the potential to falsely > timing out > > and the sender gets a 500 response). > > I agree this should go. We may want to discuss possibility of > establishing a replacement media session and then retrying the message > there. In that case I think we perhaps should make it permissible for > the retry to use the same TR-ID. It is then optional whether the > recipient detects the duplicate or not. I don't mind mentioning that some implementations might choose to create a new session and attempt to resume a conversation--but I do not want to imply that it should or should not be done. As far as retrying the same TR-ID, I do not think that is useful unless we strengthen the uniqueness requirements for TR-ID, and recommend some period of time that an endpoint should remember previous ones it had seen. > > This addresses the case where a relay crashes in an ungraceful way. > >> - Open issue: NO. > > > I guess what I am proposing is YES, but with a weak mechanism - neither > side is *required* to enable duplicate suppression, but the mechanism is > there if both sides choose to use it. > I assume the weak mechanism to which you refer is the TR-ID approach mentioned above. See my comments above. > Paul > > > _______________________________________________ > 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-admin@ietf.org Fri Nov 7 16:28:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08585; Fri, 7 Nov 2003 16:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEA8-0003Ep-00; Fri, 07 Nov 2003 16:29:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEA8-0003Em-00; Fri, 07 Nov 2003 16:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEA9-0002Lc-2P; Fri, 07 Nov 2003 16:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE9A-0002EZ-G4 for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08526; Fri, 7 Nov 2003 16:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE98-0003E4-00; Fri, 07 Nov 2003 16:27:58 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIE97-0003Dn-00; Fri, 07 Nov 2003 16:27:57 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7LRMhL015424; Fri, 7 Nov 2003 16:27:23 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7LRLg15443; Fri, 7 Nov 2003 16:27:22 -0500 Message-ID: <3FAC0E39.7040207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> In-Reply-To: <3FAC09DC.496B33B4@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 16:27:21 -0500 Content-Transfer-Encoding: 7bit [Trimming cc list] This doesn't work under the GEOPRIV design assumption, where permissions may be composed from multiple source and where some of these sources may (temporarily) be unavailable. While it is privacy-safe to omit unavailable sources if you can only add permissions, it is distinctly unsafe to ignore external references if you subtract permissions. Even if you ignore this particular aspect, subtracting permissions does not work as in the basic arithmetic. (It's closer to set operations, actually.) I'm guessing that a user expects that once a permission has been subtracted, it can't get added back in by some other rule that also happens to match. If you enforce this, you have to enforce ordering on the way that permissions are computed: you have to first compute the additive permissions for each field, then compute all the negative permissions and remove them again. Thus, ordering matters and it becomes really difficult to understand the interaction of multiple rule makers that operate in sequence (personal policy plus corporate policy). Naturally, this also significantly complicates the computation of permissions. If you do allow 'sticky' negative permissions (override everything) and non-sticky ones (get overridden), you have now further increased the complexity of the rule computation and decreased the predictability of the system. Thus, while it may seem easy to think of adding and subtracting permissions as commutative and associative mathematical operations, they are not really. The biggest danger with security rule systems is unpredictable behavior, i.e., where the rules get sufficiently complex that the user makes mistakes in anticipating what exactly will happen under certain circumstances. Teaching users about the intricacies of sticky and non-sticky set operations does not seem, to me, a way to increase system predictability. Alex Audu wrote: > All this is not too clear to me yet, but an exception can be viewed > simply as a form negative addition. Therefore it theoretically shouldn't > violate the "additive permissions theory". > > The idea of a black list works fine in an enterprise type environment. > I think I see value in it. > > Regards, > Alex. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 16:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08637 for ; Fri, 7 Nov 2003 16:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEAB-0002OU-KE for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 16:29:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LT3jg009196 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 16:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEAB-0002OF-Ft for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 16:29:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08585; Fri, 7 Nov 2003 16:28:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEA8-0003Ep-00; Fri, 07 Nov 2003 16:29:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEA8-0003Em-00; Fri, 07 Nov 2003 16:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEA9-0002Lc-2P; Fri, 07 Nov 2003 16:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE9A-0002EZ-G4 for simple@optimus.ietf.org; Fri, 07 Nov 2003 16:28:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08526; Fri, 7 Nov 2003 16:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE98-0003E4-00; Fri, 07 Nov 2003 16:27:58 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIE97-0003Dn-00; Fri, 07 Nov 2003 16:27:57 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7LRMhL015424; Fri, 7 Nov 2003 16:27:23 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7LRLg15443; Fri, 7 Nov 2003 16:27:22 -0500 Message-ID: <3FAC0E39.7040207@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> In-Reply-To: <3FAC09DC.496B33B4@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 16:27:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit [Trimming cc list] This doesn't work under the GEOPRIV design assumption, where permissions may be composed from multiple source and where some of these sources may (temporarily) be unavailable. While it is privacy-safe to omit unavailable sources if you can only add permissions, it is distinctly unsafe to ignore external references if you subtract permissions. Even if you ignore this particular aspect, subtracting permissions does not work as in the basic arithmetic. (It's closer to set operations, actually.) I'm guessing that a user expects that once a permission has been subtracted, it can't get added back in by some other rule that also happens to match. If you enforce this, you have to enforce ordering on the way that permissions are computed: you have to first compute the additive permissions for each field, then compute all the negative permissions and remove them again. Thus, ordering matters and it becomes really difficult to understand the interaction of multiple rule makers that operate in sequence (personal policy plus corporate policy). Naturally, this also significantly complicates the computation of permissions. If you do allow 'sticky' negative permissions (override everything) and non-sticky ones (get overridden), you have now further increased the complexity of the rule computation and decreased the predictability of the system. Thus, while it may seem easy to think of adding and subtracting permissions as commutative and associative mathematical operations, they are not really. The biggest danger with security rule systems is unpredictable behavior, i.e., where the rules get sufficiently complex that the user makes mistakes in anticipating what exactly will happen under certain circumstances. Teaching users about the intricacies of sticky and non-sticky set operations does not seem, to me, a way to increase system predictability. Alex Audu wrote: > All this is not too clear to me yet, but an exception can be viewed > simply as a form negative addition. Therefore it theoretically shouldn't > violate the "additive permissions theory". > > The idea of a black list works fine in an enterprise type environment. > I think I see value in it. > > Regards, > Alex. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 17:11:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10547; Fri, 7 Nov 2003 17:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEpo-0003x8-00; Fri, 07 Nov 2003 17:12:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEpo-0003x5-00; Fri, 07 Nov 2003 17:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpk-00063R-UO; Fri, 07 Nov 2003 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpX-000638-Vd for simple@optimus.ietf.org; Fri, 07 Nov 2003 17:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10537 for ; Fri, 7 Nov 2003 17:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEpV-0003wt-00 for simple@ietf.org; Fri, 07 Nov 2003 17:11:45 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIEpV-0003w5-00 for simple@ietf.org; Fri, 07 Nov 2003 17:11:45 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7MBGca013775 for ; Fri, 7 Nov 2003 17:11:16 -0500 (EST) Message-ID: <3FAC1882.7070605@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] ad-hoc list subscriptions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 17:11:14 -0500 Content-Transfer-Encoding: 7bit Orit, Some comments on: http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-00.txt Generally, I do think we need something like this. It seems particularly useful in environments where the list is not syncrhonized with the network, but for which we want to get the benefits of list subscriptions, in terms of reducing overhead. Firstly, this feels to me like it has a lot in common with the filter work. Both this and the filter work use body objects to push policy about the subscription to the server. Both have needs for updates to these policy objects during the lifetime of the subscriptions. Both have similar lifecycle managamenet requirements. Both provide details on exactly what the subscription is for. Have you considered trying to unify this with the filter work? Indeed, it might be useful to start off with some requirements to define what we want to do here, we may not all be on the same page. Secondly, one big question is - what is the request URI? I can see several options: (1) its a well-known service URI, for example, sip:adhoclist@domain.com, where the server knows that for any subscriptions to sip:adhoclist@, it means that the subscription has its contents in the body (2) its a SIP URI that doesnt match any existing resource in the domain. Thus, the act of subscribing basically creates that resource as a list resource (3) its a CID URI, referring to the list in the body of the request I think you have (2) in mind. But, I'm not sure thats the right way to go. Thirdly, you talk about all subscribed parties to the list receiving a notify when the list content changes: > When a resource is added to /deleted from the list, the RLS SHOULD > generate a NOTIFY as if the list had been updated by any possible > out-of-band means and in accordance with the notification mechanism > and format established for this list. The updated information SHOULD > be sent to all the parties being subscribed to this list (including > the "list-owner"). I dont get this. I thought that an ad-hoc list would be scoped to the subscription, in which case, there wouldnt be any other subscribers. Am I missing something? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 17:12:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10600 for ; Fri, 7 Nov 2003 17:12:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEps-000656-9P for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 17:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7MC8c3023370 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 17:12:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEps-00064r-5F for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 17:12:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10547; Fri, 7 Nov 2003 17:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEpo-0003x8-00; Fri, 07 Nov 2003 17:12:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIEpo-0003x5-00; Fri, 07 Nov 2003 17:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpk-00063R-UO; Fri, 07 Nov 2003 17:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEpX-000638-Vd for simple@optimus.ietf.org; Fri, 07 Nov 2003 17:11:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10537 for ; Fri, 7 Nov 2003 17:11:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEpV-0003wt-00 for simple@ietf.org; Fri, 07 Nov 2003 17:11:45 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIEpV-0003w5-00 for simple@ietf.org; Fri, 07 Nov 2003 17:11:45 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA7MBGca013775 for ; Fri, 7 Nov 2003 17:11:16 -0500 (EST) Message-ID: <3FAC1882.7070605@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 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 Content-Transfer-Encoding: 7bit Subject: [Simple] ad-hoc list subscriptions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 17:11:14 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit, Some comments on: http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-00.txt Generally, I do think we need something like this. It seems particularly useful in environments where the list is not syncrhonized with the network, but for which we want to get the benefits of list subscriptions, in terms of reducing overhead. Firstly, this feels to me like it has a lot in common with the filter work. Both this and the filter work use body objects to push policy about the subscription to the server. Both have needs for updates to these policy objects during the lifetime of the subscriptions. Both have similar lifecycle managamenet requirements. Both provide details on exactly what the subscription is for. Have you considered trying to unify this with the filter work? Indeed, it might be useful to start off with some requirements to define what we want to do here, we may not all be on the same page. Secondly, one big question is - what is the request URI? I can see several options: (1) its a well-known service URI, for example, sip:adhoclist@domain.com, where the server knows that for any subscriptions to sip:adhoclist@, it means that the subscription has its contents in the body (2) its a SIP URI that doesnt match any existing resource in the domain. Thus, the act of subscribing basically creates that resource as a list resource (3) its a CID URI, referring to the list in the body of the request I think you have (2) in mind. But, I'm not sure thats the right way to go. Thirdly, you talk about all subscribed parties to the list receiving a notify when the list content changes: > When a resource is added to /deleted from the list, the RLS SHOULD > generate a NOTIFY as if the list had been updated by any possible > out-of-band means and in accordance with the notification mechanism > and format established for this list. The updated information SHOULD > be sent to all the parties being subscribed to this list (including > the "list-owner"). I dont get this. I thought that an ad-hoc list would be scoped to the subscription, in which case, there wouldnt be any other subscribers. Am I missing something? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 18:11:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13177; Fri, 7 Nov 2003 18:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFlq-0004dk-00; Fri, 07 Nov 2003 18:12:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIFlq-0004dh-00; Fri, 07 Nov 2003 18:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFlp-0001Cw-Qh; Fri, 07 Nov 2003 18:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFks-00018T-TK for simple@optimus.ietf.org; Fri, 07 Nov 2003 18:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13082 for ; Fri, 7 Nov 2003 18:10:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFkq-0004d4-00 for simple@ietf.org; Fri, 07 Nov 2003 18:11:00 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIFkp-0004cj-00 for simple@ietf.org; Fri, 07 Nov 2003 18:10:59 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2003 15:11:32 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA7NAQw5018483; Fri, 7 Nov 2003 15:10:26 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADV26984; Fri, 7 Nov 2003 18:10:25 -0500 (EST) Message-ID: <3FAC2661.70106@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 18:10:25 -0500 Content-Transfer-Encoding: 7bit inline... Ben Campbell wrote: > Paul Kyzivat wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> >>> - Section 7.4.3: >>> - In step 5 "The endpoint MAY attempt to send the message content >>> again" >> >> >> > Should we remove this text? If the message sending fails, so >> be it. >> > The user can choose to send it again. This avoids the very >> large message >> > being sent again (long messages have the potential to falsely >> timing out >> > and the sender gets a 500 response). >> >> I agree this should go. We may want to discuss possibility of >> establishing a replacement media session and then retrying the message >> there. In that case I think we perhaps should make it permissible for >> the retry to use the same TR-ID. It is then optional whether the >> recipient detects the duplicate or not. > > I don't mind mentioning that some implementations might choose to create > a new session and attempt to resume a conversation--but I do not want to > imply that it should or should not be done. I agree it should be an application issue whether to do this. > As far as retrying the same > TR-ID, I do not think that is useful unless we strengthen the uniqueness > requirements for TR-ID, and recommend some period of time that an > endpoint should remember previous ones it had seen. I'm not certain a time period is really necessary. I think this can be local option. Even uniqueness across streams isn't *required*, though it would be helpful. Instead, we can simply introduce an error response to be used when a duplicate is detected and supressed. If it was supressed in error because the sender duplicated a TR-ID from another stream, the sender would then know to recover. But I agree that some further clarification on TR-ID uniqueness could be helpful. >> This addresses the case where a relay crashes in an ungraceful way. >> >>> - Open issue: NO. >> >> I guess what I am proposing is YES, but with a weak mechanism - >> neither side is *required* to enable duplicate suppression, but the >> mechanism is there if both sides choose to use it. > > I assume the weak mechanism to which you refer is the TR-ID approach > mentioned above. See my comments above. yes. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 18:12:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13242 for ; Fri, 7 Nov 2003 18:12:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFlv-0001Dk-KL for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 18:12:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7NC78h004686 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 18:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFlu-0001DV-4A for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 18:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13177; Fri, 7 Nov 2003 18:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFlq-0004dk-00; Fri, 07 Nov 2003 18:12:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIFlq-0004dh-00; Fri, 07 Nov 2003 18:12:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFlp-0001Cw-Qh; Fri, 07 Nov 2003 18:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIFks-00018T-TK for simple@optimus.ietf.org; Fri, 07 Nov 2003 18:11:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13082 for ; Fri, 7 Nov 2003 18:10:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIFkq-0004d4-00 for simple@ietf.org; Fri, 07 Nov 2003 18:11:00 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AIFkp-0004cj-00 for simple@ietf.org; Fri, 07 Nov 2003 18:10:59 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2003 15:11:32 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA7NAQw5018483; Fri, 7 Nov 2003 15:10:26 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADV26984; Fri, 7 Nov 2003 18:10:25 -0500 (EST) Message-ID: <3FAC2661.70106@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 18:10:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline... Ben Campbell wrote: > Paul Kyzivat wrote: > >> hisham.khartabil@nokia.com wrote: >> >>> >>> - Section 7.4.3: >>> - In step 5 "The endpoint MAY attempt to send the message content >>> again" >> >> >> > Should we remove this text? If the message sending fails, so >> be it. >> > The user can choose to send it again. This avoids the very >> large message >> > being sent again (long messages have the potential to falsely >> timing out >> > and the sender gets a 500 response). >> >> I agree this should go. We may want to discuss possibility of >> establishing a replacement media session and then retrying the message >> there. In that case I think we perhaps should make it permissible for >> the retry to use the same TR-ID. It is then optional whether the >> recipient detects the duplicate or not. > > I don't mind mentioning that some implementations might choose to create > a new session and attempt to resume a conversation--but I do not want to > imply that it should or should not be done. I agree it should be an application issue whether to do this. > As far as retrying the same > TR-ID, I do not think that is useful unless we strengthen the uniqueness > requirements for TR-ID, and recommend some period of time that an > endpoint should remember previous ones it had seen. I'm not certain a time period is really necessary. I think this can be local option. Even uniqueness across streams isn't *required*, though it would be helpful. Instead, we can simply introduce an error response to be used when a duplicate is detected and supressed. If it was supressed in error because the sender duplicated a TR-ID from another stream, the sender would then know to recover. But I agree that some further clarification on TR-ID uniqueness could be helpful. >> This addresses the case where a relay crashes in an ungraceful way. >> >>> - Open issue: NO. >> >> I guess what I am proposing is YES, but with a weak mechanism - >> neither side is *required* to enable duplicate suppression, but the >> mechanism is there if both sides choose to use it. > > I assume the weak mechanism to which you refer is the TR-ID approach > mentioned above. See my comments above. yes. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 7 22:30:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20836; Fri, 7 Nov 2003 22:30:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJob-00000N-00; Fri, 07 Nov 2003 22:31:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIJoa-00000K-00; Fri, 07 Nov 2003 22:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJoU-0003os-5a; Fri, 07 Nov 2003 22:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJo5-0003ne-1q for simple@optimus.ietf.org; Fri, 07 Nov 2003 22:30:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20814; Fri, 7 Nov 2003 22:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJo1-0007n9-00; Fri, 07 Nov 2003 22:30:33 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIJo0-0007ms-00; Fri, 07 Nov 2003 22:30:33 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA83TxhL002162; Fri, 7 Nov 2003 22:30:00 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA83Tvf23450; Fri, 7 Nov 2003 22:29:57 -0500 Message-ID: <3FAC6335.2020109@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> In-Reply-To: <3FABFECE.4040606@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 22:29:57 -0500 Content-Transfer-Encoding: 7bit > I share Ito-san's confusion here. Assuming the same kind of > restrictions you have asked for - no external references, no > wildcards, no domain-scopes, I dont see the difference between: > > > example.com > > joe@example.com > > > > and: > > > example.com > > > > joe@example.com > > > THe differences seem merely syntactic, but maybe I am missing > something here. GEOPRIV has, so far, insisted on allowing inclusions and others have insisted on wildcards. By separating the two tables, you can have inclusions and wildcards in the 'additive' table, and limit the restrictions to the exceptions table. The WGs need to make an explicit choice between three options: (1a and 1b) Impose restrictions on table composition (no multi-stage policies, no dynamic composition and failure on non-reachability during static composition). In that case, exceptions can be made to work, either for a single table (case 1a; if the restrictions apply to that table) or as two tables (case 1b; if only the exceptions table is thus restricted). Dynamic composition = composing permissions while evaluating rules (e.g., by having a reference in PIDF-LO, as in the 'ruleset-reference' parameter in draft-peterson-geopriv-pidf-lo-02.txt) Static composition = inclusion by reference when loading permissions into the LS or PA My understanding is that XCAP currently allows neither mode of composition, so the problem is not as pronounced there. I think it would be really confusing and error-prone if, say, the PIDF-LO 'ruleset-reference' could not include blacklists, while files uploaded from the RM into the LS could. (2) Allow dynamic composition, but no exceptions. Maybe we should first determine if there are other options, so that we can pose the correct choices. > > Henning also wrote: > >> Blacklists were popular for spam-protection early on, but I think >> everyone has realized by now that they are close to useless. I'd >> hate to create a complicated, brittle, difficult-to-predict system >> just to find out a year later that this expensive feature turned >> out to be mostly an empty promise, in terms of increasing user >> privacy. > > > There are some serious differences here with the email spam case. > Firstly, the systems we are talking about require authentication, which > is absent in email. Secondly, and perhaps most importantly, I am not > interested in rules like "allow anyone in the world but > bob@example.com", as I agree this is silly. We are talking about rules > like "allow only people from example.com EXCEPT bob@example.com". That > is, I expect these systems to require a user to explicitly grant a > permission, but an extremely common case, I think, will be to grant it > by indicating a domain with a set of exceptions. Authentication is not terribly important here, but rather the ease of creating new identities within a domain. Note, in particular, that the authenticated name in a SIMPLE context may or may not correspond 1-1 to the From identifier. There is nothing that prevents (or should prevent) allowing something like the foo+anything mechanism, with a single login (Digest) identity. Thus, a user who wants to use blacklists reliably has to have a fairly detailed understanding of the identity creation and authentication policies in the domain. I'm not arguing that they will never work, just that they will often fail in surprising ways. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 7 22:31:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20921 for ; Fri, 7 Nov 2003 22:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJof-0003rp-RX for simple-archive@odin.ietf.org; Fri, 07 Nov 2003 22:31:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA83VDkZ014859 for simple-archive@odin.ietf.org; Fri, 7 Nov 2003 22:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJof-0003ra-O0 for simple-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 22:31:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20836; Fri, 7 Nov 2003 22:30:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJob-00000N-00; Fri, 07 Nov 2003 22:31:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIJoa-00000K-00; Fri, 07 Nov 2003 22:31:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJoU-0003os-5a; Fri, 07 Nov 2003 22:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJo5-0003ne-1q for simple@optimus.ietf.org; Fri, 07 Nov 2003 22:30:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20814; Fri, 7 Nov 2003 22:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJo1-0007n9-00; Fri, 07 Nov 2003 22:30:33 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIJo0-0007ms-00; Fri, 07 Nov 2003 22:30:33 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA83TxhL002162; Fri, 7 Nov 2003 22:30:00 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA83Tvf23450; Fri, 7 Nov 2003 22:29:57 -0500 Message-ID: <3FAC6335.2020109@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> In-Reply-To: <3FABFECE.4040606@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 22:29:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I share Ito-san's confusion here. Assuming the same kind of > restrictions you have asked for - no external references, no > wildcards, no domain-scopes, I dont see the difference between: > > > example.com > > joe@example.com > > > > and: > > > example.com > > > > joe@example.com > > > THe differences seem merely syntactic, but maybe I am missing > something here. GEOPRIV has, so far, insisted on allowing inclusions and others have insisted on wildcards. By separating the two tables, you can have inclusions and wildcards in the 'additive' table, and limit the restrictions to the exceptions table. The WGs need to make an explicit choice between three options: (1a and 1b) Impose restrictions on table composition (no multi-stage policies, no dynamic composition and failure on non-reachability during static composition). In that case, exceptions can be made to work, either for a single table (case 1a; if the restrictions apply to that table) or as two tables (case 1b; if only the exceptions table is thus restricted). Dynamic composition = composing permissions while evaluating rules (e.g., by having a reference in PIDF-LO, as in the 'ruleset-reference' parameter in draft-peterson-geopriv-pidf-lo-02.txt) Static composition = inclusion by reference when loading permissions into the LS or PA My understanding is that XCAP currently allows neither mode of composition, so the problem is not as pronounced there. I think it would be really confusing and error-prone if, say, the PIDF-LO 'ruleset-reference' could not include blacklists, while files uploaded from the RM into the LS could. (2) Allow dynamic composition, but no exceptions. Maybe we should first determine if there are other options, so that we can pose the correct choices. > > Henning also wrote: > >> Blacklists were popular for spam-protection early on, but I think >> everyone has realized by now that they are close to useless. I'd >> hate to create a complicated, brittle, difficult-to-predict system >> just to find out a year later that this expensive feature turned >> out to be mostly an empty promise, in terms of increasing user >> privacy. > > > There are some serious differences here with the email spam case. > Firstly, the systems we are talking about require authentication, which > is absent in email. Secondly, and perhaps most importantly, I am not > interested in rules like "allow anyone in the world but > bob@example.com", as I agree this is silly. We are talking about rules > like "allow only people from example.com EXCEPT bob@example.com". That > is, I expect these systems to require a user to explicitly grant a > permission, but an extremely common case, I think, will be to grant it > by indicating a domain with a set of exceptions. Authentication is not terribly important here, but rather the ease of creating new identities within a domain. Note, in particular, that the authenticated name in a SIMPLE context may or may not correspond 1-1 to the From identifier. There is nothing that prevents (or should prevent) allowing something like the foo+anything mechanism, with a single login (Digest) identity. Thus, a user who wants to use blacklists reliably has to have a fairly detailed understanding of the identity creation and authentication policies in the domain. I'm not arguing that they will never work, just that they will often fail in surprising ways. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 8 00:43:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23582; Sat, 8 Nov 2003 00:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILsQ-0001Ma-00; Sat, 08 Nov 2003 00:43:14 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AILsP-0001MX-00; Sat, 08 Nov 2003 00:43:13 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AILsR-0006Oj-4y; Sat, 08 Nov 2003 00:43:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILsD-0000n8-Ar; Sat, 08 Nov 2003 00:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILrL-0000mF-Q9 for simple@optimus.ietf.org; Sat, 08 Nov 2003 00:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23572; Sat, 8 Nov 2003 00:41:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILrI-0001MM-00; Sat, 08 Nov 2003 00:42:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AILrH-0001MF-00; Sat, 08 Nov 2003 00:42:03 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA85e0ca013883; Sat, 8 Nov 2003 00:40:00 -0500 (EST) Message-ID: <3FAC81AE.4010905@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: alex.audu@alcatel.com, Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> In-Reply-To: <3FAC0E39.7040207@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 00:39:58 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > [Trimming cc list] > > This doesn't work under the GEOPRIV design assumption, where permissions > may be composed from multiple source and where some of these sources may > (temporarily) be unavailable. While it is privacy-safe to omit > unavailable sources if you can only add permissions, it is distinctly > unsafe to ignore external references if you subtract permissions. Henning, we still have a fundamental disconnect here. No one is saying that there is negative permissions here that can be fetched by external reference. In particular, I am NOT proposing that you can have a pure exception permission. Rather, a permission is always additive, but merely defines the set of users that get added by specifying a base plus a set of users to remove from that base. To be concrete, I would agree that the set of users listed in any except clauses *MUST* also be present in a non-except clause in the same applies-to statement. This guarantees that the overall applies-to statement is purely additive. For example, a statement might look like: example.com sip:user@example.com This is an *additive* permission. It defines a set of users (everyone in example.com but user) that now get these new permissions. If the above statement cannot be obtained, those users won't get the specified permissions. Based on my definitions, the following is NOT A LEGAL DOCUMENT: example.com sip:user@foo.com Here, you would definitely have the problems you describe. I am agreeing we should not allow this case. > > Even if you ignore this particular aspect, subtracting permissions does > not work as in the basic arithmetic. (It's closer to set operations, > actually.) > > I'm guessing that a user expects that once a permission has been > subtracted, it can't get added back in by some other rule that also > happens to match. If you enforce this, you have to enforce ordering on > the way that permissions are computed: you have to first compute the > additive permissions for each field, then compute all the negative > permissions and remove them again. Thus, ordering matters and it becomes > really difficult to understand the interaction of multiple rule makers > that operate in sequence (personal policy plus corporate policy). > Naturally, this also significantly complicates the computation of > permissions. > > If you do allow 'sticky' negative permissions (override everything) and > non-sticky ones (get overridden), you have now further increased the > complexity of the rule computation and decreased the predictability of > the system. > > Thus, while it may seem easy to think of adding and subtracting > permissions as commutative and associative mathematical operations, they > are not really. > > The biggest danger with security rule systems is unpredictable behavior, > i.e., where the rules get sufficiently complex that the user makes > mistakes in anticipating what exactly will happen under certain > circumstances. Teaching users about the intricacies of sticky and > non-sticky set operations does not seem, to me, a way to increase system > predictability. Agreed here on all points. Please see my above description. Hopefully this clarifies that the proposed exception mechanism is not creating negative permissions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 8 00:43:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23620 for ; Sat, 8 Nov 2003 00:43:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILsV-0000qS-RT for simple-archive@odin.ietf.org; Sat, 08 Nov 2003 00:43:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA85hJBx003242 for simple-archive@odin.ietf.org; Sat, 8 Nov 2003 00:43:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILsV-0000qD-Ma for simple-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 00:43:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23582; Sat, 8 Nov 2003 00:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILsQ-0001Ma-00; Sat, 08 Nov 2003 00:43:14 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AILsP-0001MX-00; Sat, 08 Nov 2003 00:43:13 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AILsR-0006Oj-4y; Sat, 08 Nov 2003 00:43:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILsD-0000n8-Ar; Sat, 08 Nov 2003 00:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILrL-0000mF-Q9 for simple@optimus.ietf.org; Sat, 08 Nov 2003 00:42:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23572; Sat, 8 Nov 2003 00:41:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILrI-0001MM-00; Sat, 08 Nov 2003 00:42:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AILrH-0001MF-00; Sat, 08 Nov 2003 00:42:03 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA85e0ca013883; Sat, 8 Nov 2003 00:40:00 -0500 (EST) Message-ID: <3FAC81AE.4010905@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: alex.audu@alcatel.com, Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> In-Reply-To: <3FAC0E39.7040207@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 00:39:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > [Trimming cc list] > > This doesn't work under the GEOPRIV design assumption, where permissions > may be composed from multiple source and where some of these sources may > (temporarily) be unavailable. While it is privacy-safe to omit > unavailable sources if you can only add permissions, it is distinctly > unsafe to ignore external references if you subtract permissions. Henning, we still have a fundamental disconnect here. No one is saying that there is negative permissions here that can be fetched by external reference. In particular, I am NOT proposing that you can have a pure exception permission. Rather, a permission is always additive, but merely defines the set of users that get added by specifying a base plus a set of users to remove from that base. To be concrete, I would agree that the set of users listed in any except clauses *MUST* also be present in a non-except clause in the same applies-to statement. This guarantees that the overall applies-to statement is purely additive. For example, a statement might look like: example.com sip:user@example.com This is an *additive* permission. It defines a set of users (everyone in example.com but user) that now get these new permissions. If the above statement cannot be obtained, those users won't get the specified permissions. Based on my definitions, the following is NOT A LEGAL DOCUMENT: example.com sip:user@foo.com Here, you would definitely have the problems you describe. I am agreeing we should not allow this case. > > Even if you ignore this particular aspect, subtracting permissions does > not work as in the basic arithmetic. (It's closer to set operations, > actually.) > > I'm guessing that a user expects that once a permission has been > subtracted, it can't get added back in by some other rule that also > happens to match. If you enforce this, you have to enforce ordering on > the way that permissions are computed: you have to first compute the > additive permissions for each field, then compute all the negative > permissions and remove them again. Thus, ordering matters and it becomes > really difficult to understand the interaction of multiple rule makers > that operate in sequence (personal policy plus corporate policy). > Naturally, this also significantly complicates the computation of > permissions. > > If you do allow 'sticky' negative permissions (override everything) and > non-sticky ones (get overridden), you have now further increased the > complexity of the rule computation and decreased the predictability of > the system. > > Thus, while it may seem easy to think of adding and subtracting > permissions as commutative and associative mathematical operations, they > are not really. > > The biggest danger with security rule systems is unpredictable behavior, > i.e., where the rules get sufficiently complex that the user makes > mistakes in anticipating what exactly will happen under certain > circumstances. Teaching users about the intricacies of sticky and > non-sticky set operations does not seem, to me, a way to increase system > predictability. Agreed here on all points. Please see my above description. Hopefully this clarifies that the proposed exception mechanism is not creating negative permissions. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 8 00:48:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23737; Sat, 8 Nov 2003 00:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILxG-0001Su-00; Sat, 08 Nov 2003 00:48:14 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AILxG-0001Sr-00; Sat, 08 Nov 2003 00:48:14 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AILxE-0006S2-C1; Sat, 08 Nov 2003 00:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILx3-000121-O2; Sat, 08 Nov 2003 00:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILwc-000102-HM for simple@optimus.ietf.org; Sat, 08 Nov 2003 00:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23727; Sat, 8 Nov 2003 00:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILwY-0001SY-00; Sat, 08 Nov 2003 00:47:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AILwX-0001SD-00; Sat, 08 Nov 2003 00:47:30 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA85krca013886; Sat, 8 Nov 2003 00:46:54 -0500 (EST) Message-ID: <3FAC834C.1080708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Henning Schulzrinne , Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 00:46:52 -0500 Content-Transfer-Encoding: 7bit inline. hardie@qualcomm.com wrote: > At 3:21 PM -0500 11/07/2003, Jonathan Rosenberg wrote: > >> To summarize (correct me if I am wrong), I think your suggestion >> was that exceptions can be handled by expanding the lists >> associated with the domain. As such, even though the user sees an >> exception rule in the UI, the underlying system pushes a >> permission with everyone in it. > > > I'm saying that's the protocol's view of the permission and the > structure in which they're encoded and sent. How the underlying > system store the permissions is, I think, a local optimization. Agreed. Thats different from what I was saying above, which is that the way a UI shows permissions, and the protocol's views of a permission, can also be different. > > > >> My concern is that I believe this will be very difficult to >> manage. It requires the users to have access to the set of users >> in the domain from which the exceptions are being specified. That >> list is undoubtedly dynamic, and potentially pretty large. When a >> new employee joins the company, everyone would have to update >> their permissiosn (or have their agents do it automatically >> somehow), and similarly when someone leaves. The result will be >> odd behavior for users, where people that a user believes to have >> permission, actually doesnt. >> > > > This gets one of the points I was trying to make earlier; the > difficulty here depends on how the group data is structured. Let's > assume that we have a very wide, flat identifier, like > "user@qualcomm.com"; granting to domain "qualcomm.com" with an > except on the basis of that identifier would be tough. Why? I don't understand. This identifier is not flat - it has a clear user and domain part, which are separable. > If the > identifiers were not email-like, though, but based on group > identifiers that were more distributed, then granting them is > slightly more tedious, but the except clauses become easier--as it > is a flat grant to groups 1-100, and increased grant to groups 1-9 > and 11-100, an increased grant to member 1,3,4 of group 10, and a > failure to grant to member 2 of group 10. This does mean that > adding to member 5 to group 10 creates a synchronization problem. > There are ways around that, and they are tedious and potentially > flakey. > > You don't need to use them, though, unless you are doing exception > based processing. If this is very common, we may need to change > our view of what is critical. In the short term, I believe that > getting to the point where the user can grant permissions on a > "domain" (not necessarily DNS label) is considerably beyond where > we are today, and I think a lot of the real need in GeoPriv is > handled by the explicit grant case. For consumer applications, I would be inclined to agree. I don't see this as practical at all for any enterprise applications of geoloc. That is, applications where a wireless provider is providing an application (such as a sales force automation app) to an enterprise. > > Doing exception based processing might be possible, but it seems to > put a burden on the processor that requires it to ensure it has > processed *all rules* before it can proceed (perhaps a better way > to put this is that it has processed all "includes" before it can > proceed). If it does not process all rules, there seems to be a > not trivial risk that user@qualcomm.com (a.k.a. Member 2 of group > 10) gets data that the privacy policy doesn't allow. That's simple > not okay in the GeoPriv view of the world. In the exception model I am talking about, this is not the case. It is not true that lack of processing of a rule can leak data that shouldn't be leaked. Hopefully my response to Henning clarifies this. I think the disconnect is that I am NOT proposing pure exceptions. I am merely using exceptions as a short hand to avoid enumerating long lists of people to whom a rule applies. That is, an applies-to statement has a positive component (the domain to which the rule applies), and a set of exceptions that remove users from THAT domain. THis is functionally equivalent to enumerating all users in the domain except the ones I don't like, which is clearly an additive permission. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 8 00:48:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23779 for ; Sat, 8 Nov 2003 00:48:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILxL-000160-Lz for simple-archive@odin.ietf.org; Sat, 08 Nov 2003 00:48:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA85mJWF004206 for simple-archive@odin.ietf.org; Sat, 8 Nov 2003 00:48:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILxL-00015l-IH for simple-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 00:48:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23737; Sat, 8 Nov 2003 00:48:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILxG-0001Su-00; Sat, 08 Nov 2003 00:48:14 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AILxG-0001Sr-00; Sat, 08 Nov 2003 00:48:14 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AILxE-0006S2-C1; Sat, 08 Nov 2003 00:48:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILx3-000121-O2; Sat, 08 Nov 2003 00:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AILwc-000102-HM for simple@optimus.ietf.org; Sat, 08 Nov 2003 00:47:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23727; Sat, 8 Nov 2003 00:47:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AILwY-0001SY-00; Sat, 08 Nov 2003 00:47:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AILwX-0001SD-00; Sat, 08 Nov 2003 00:47:30 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA85krca013886; Sat, 8 Nov 2003 00:46:54 -0500 (EST) Message-ID: <3FAC834C.1080708@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hardie@qualcomm.com CC: Henning Schulzrinne , Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 00:46:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hardie@qualcomm.com wrote: > At 3:21 PM -0500 11/07/2003, Jonathan Rosenberg wrote: > >> To summarize (correct me if I am wrong), I think your suggestion >> was that exceptions can be handled by expanding the lists >> associated with the domain. As such, even though the user sees an >> exception rule in the UI, the underlying system pushes a >> permission with everyone in it. > > > I'm saying that's the protocol's view of the permission and the > structure in which they're encoded and sent. How the underlying > system store the permissions is, I think, a local optimization. Agreed. Thats different from what I was saying above, which is that the way a UI shows permissions, and the protocol's views of a permission, can also be different. > > > >> My concern is that I believe this will be very difficult to >> manage. It requires the users to have access to the set of users >> in the domain from which the exceptions are being specified. That >> list is undoubtedly dynamic, and potentially pretty large. When a >> new employee joins the company, everyone would have to update >> their permissiosn (or have their agents do it automatically >> somehow), and similarly when someone leaves. The result will be >> odd behavior for users, where people that a user believes to have >> permission, actually doesnt. >> > > > This gets one of the points I was trying to make earlier; the > difficulty here depends on how the group data is structured. Let's > assume that we have a very wide, flat identifier, like > "user@qualcomm.com"; granting to domain "qualcomm.com" with an > except on the basis of that identifier would be tough. Why? I don't understand. This identifier is not flat - it has a clear user and domain part, which are separable. > If the > identifiers were not email-like, though, but based on group > identifiers that were more distributed, then granting them is > slightly more tedious, but the except clauses become easier--as it > is a flat grant to groups 1-100, and increased grant to groups 1-9 > and 11-100, an increased grant to member 1,3,4 of group 10, and a > failure to grant to member 2 of group 10. This does mean that > adding to member 5 to group 10 creates a synchronization problem. > There are ways around that, and they are tedious and potentially > flakey. > > You don't need to use them, though, unless you are doing exception > based processing. If this is very common, we may need to change > our view of what is critical. In the short term, I believe that > getting to the point where the user can grant permissions on a > "domain" (not necessarily DNS label) is considerably beyond where > we are today, and I think a lot of the real need in GeoPriv is > handled by the explicit grant case. For consumer applications, I would be inclined to agree. I don't see this as practical at all for any enterprise applications of geoloc. That is, applications where a wireless provider is providing an application (such as a sales force automation app) to an enterprise. > > Doing exception based processing might be possible, but it seems to > put a burden on the processor that requires it to ensure it has > processed *all rules* before it can proceed (perhaps a better way > to put this is that it has processed all "includes" before it can > proceed). If it does not process all rules, there seems to be a > not trivial risk that user@qualcomm.com (a.k.a. Member 2 of group > 10) gets data that the privacy policy doesn't allow. That's simple > not okay in the GeoPriv view of the world. In the exception model I am talking about, this is not the case. It is not true that lack of processing of a rule can leak data that shouldn't be leaked. Hopefully my response to Henning clarifies this. I think the disconnect is that I am NOT proposing pure exceptions. I am merely using exceptions as a short hand to avoid enumerating long lists of people to whom a rule applies. That is, an applies-to statement has a positive component (the domain to which the rule applies), and a set of exceptions that remove users from THAT domain. THis is functionally equivalent to enumerating all users in the domain except the ones I don't like, which is clearly an additive permission. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 8 01:13:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24493; Sat, 8 Nov 2003 01:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMLN-0001o4-00; Sat, 08 Nov 2003 01:13:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIMLM-0001o1-00; Sat, 08 Nov 2003 01:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMLE-0002UN-VM; Sat, 08 Nov 2003 01:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMKn-0002TQ-Vs for simple@optimus.ietf.org; Sat, 08 Nov 2003 01:12:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24480; Sat, 8 Nov 2003 01:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMKk-0001nU-00; Sat, 08 Nov 2003 01:12:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIMKk-0001nB-00; Sat, 08 Nov 2003 01:12:30 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA86Brca013894; Sat, 8 Nov 2003 01:11:53 -0500 (EST) Message-ID: <3FAC8928.9040500@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> <3FAC6335.2020109@cs.columbia.edu> In-Reply-To: <3FAC6335.2020109@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 01:11:52 -0500 Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> I share Ito-san's confusion here. Assuming the same kind of >> restrictions you have asked for - no external references, no >> wildcards, no domain-scopes, I dont see the difference between: >> >> >> example.com >> >> joe@example.com >> >> >> >> and: >> >> >> example.com >> >> >> >> joe@example.com >> >> >> THe differences seem merely syntactic, but maybe I am missing >> something here. > > > GEOPRIV has, so far, insisted on allowing inclusions and others have > insisted on wildcards. By separating the two tables, you can have > inclusions and wildcards in the 'additive' table, and limit the > restrictions to the exceptions table. OK, I can agree to that, but again I dont see the need for a physically separated listing. ALl you need to do is specify that the set of elements in the exception list cannot be wildcarded. > > The WGs need to make an explicit choice between three options: > > (1a and 1b) Impose restrictions on table composition (no multi-stage > policies, no dynamic composition and failure on non-reachability during > static composition). In that case, exceptions can be made to work, > either for a single table (case 1a; if the restrictions apply to that > table) or as two tables (case 1b; if only the exceptions table is thus > restricted). > > Dynamic composition = composing permissions while evaluating rules > (e.g., by having a reference in PIDF-LO, as in the 'ruleset-reference' > parameter in draft-peterson-geopriv-pidf-lo-02.txt) > > Static composition = inclusion by reference when loading permissions > into the LS or PA > > My understanding is that XCAP currently allows neither mode of > composition, so the problem is not as pronounced there. > > I think it would be really confusing and error-prone if, say, the > PIDF-LO 'ruleset-reference' could not include blacklists, while files > uploaded from the RM into the LS could. > > (2) Allow dynamic composition, but no exceptions. Again - the exceptions mechanism I am proposing does NOT have the problem of causing leakage of information in the case that the rule cannot be fetched, either in the static or dynamic cases. >> There are some serious differences here with the email spam case. >> Firstly, the systems we are talking about require authentication, >> which is absent in email. Secondly, and perhaps most importantly, I am >> not interested in rules like "allow anyone in the world but >> bob@example.com", as I agree this is silly. We are talking about rules >> like "allow only people from example.com EXCEPT bob@example.com". That >> is, I expect these systems to require a user to explicitly grant a >> permission, but an extremely common case, I think, will be to grant it >> by indicating a domain with a set of exceptions. > > > Authentication is not terribly important here, but rather the ease of > creating new identities within a domain. They are related. Because of authentication, creation of a new identity requires establishment of credentials for that identity. Since this needs to be handled by the domain administrator, it seems that it is much easier to manage these identities. > > Note, in particular, that the authenticated name in a SIMPLE context may > or may not correspond 1-1 to the From identifier. There is nothing that > prevents (or should prevent) allowing something like the foo+anything > mechanism, with a single login (Digest) identity. > > Thus, a user who wants to use blacklists reliably has to have a fairly > detailed understanding of the identity creation and authentication > policies in the domain. > > I'm not arguing that they will never work, just that they will often > fail in surprising ways. To me, this feels like throwing away the baby with the bathwater. Just because there will be domains with name allocation policies that make it easy to get new names, does not mean that a system should never support black lists. I believe that the need for authentication in these systems will go hand in hand with identity management which generally will make it hard to readily obtain new names (and in particular, new names with new credentials). Of course, there can be cases where this is not true. I'd rather deal with that using caveats in the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 8 01:13:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24535 for ; Sat, 8 Nov 2003 01:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMLR-0002Zq-FI for simple-archive@odin.ietf.org; Sat, 08 Nov 2003 01:13:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA86DDrG009900 for simple-archive@odin.ietf.org; Sat, 8 Nov 2003 01:13:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMLR-0002Zb-Bt for simple-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 01:13:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24493; Sat, 8 Nov 2003 01:13:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMLN-0001o4-00; Sat, 08 Nov 2003 01:13:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIMLM-0001o1-00; Sat, 08 Nov 2003 01:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMLE-0002UN-VM; Sat, 08 Nov 2003 01:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMKn-0002TQ-Vs for simple@optimus.ietf.org; Sat, 08 Nov 2003 01:12:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24480; Sat, 8 Nov 2003 01:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMKk-0001nU-00; Sat, 08 Nov 2003 01:12:30 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIMKk-0001nB-00; Sat, 08 Nov 2003 01:12:30 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA86Brca013894; Sat, 8 Nov 2003 01:11:53 -0500 (EST) Message-ID: <3FAC8928.9040500@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> <3FAC6335.2020109@cs.columbia.edu> In-Reply-To: <3FAC6335.2020109@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 01:11:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Henning Schulzrinne wrote: >> I share Ito-san's confusion here. Assuming the same kind of >> restrictions you have asked for - no external references, no >> wildcards, no domain-scopes, I dont see the difference between: >> >> >> example.com >> >> joe@example.com >> >> >> >> and: >> >> >> example.com >> >> >> >> joe@example.com >> >> >> THe differences seem merely syntactic, but maybe I am missing >> something here. > > > GEOPRIV has, so far, insisted on allowing inclusions and others have > insisted on wildcards. By separating the two tables, you can have > inclusions and wildcards in the 'additive' table, and limit the > restrictions to the exceptions table. OK, I can agree to that, but again I dont see the need for a physically separated listing. ALl you need to do is specify that the set of elements in the exception list cannot be wildcarded. > > The WGs need to make an explicit choice between three options: > > (1a and 1b) Impose restrictions on table composition (no multi-stage > policies, no dynamic composition and failure on non-reachability during > static composition). In that case, exceptions can be made to work, > either for a single table (case 1a; if the restrictions apply to that > table) or as two tables (case 1b; if only the exceptions table is thus > restricted). > > Dynamic composition = composing permissions while evaluating rules > (e.g., by having a reference in PIDF-LO, as in the 'ruleset-reference' > parameter in draft-peterson-geopriv-pidf-lo-02.txt) > > Static composition = inclusion by reference when loading permissions > into the LS or PA > > My understanding is that XCAP currently allows neither mode of > composition, so the problem is not as pronounced there. > > I think it would be really confusing and error-prone if, say, the > PIDF-LO 'ruleset-reference' could not include blacklists, while files > uploaded from the RM into the LS could. > > (2) Allow dynamic composition, but no exceptions. Again - the exceptions mechanism I am proposing does NOT have the problem of causing leakage of information in the case that the rule cannot be fetched, either in the static or dynamic cases. >> There are some serious differences here with the email spam case. >> Firstly, the systems we are talking about require authentication, >> which is absent in email. Secondly, and perhaps most importantly, I am >> not interested in rules like "allow anyone in the world but >> bob@example.com", as I agree this is silly. We are talking about rules >> like "allow only people from example.com EXCEPT bob@example.com". That >> is, I expect these systems to require a user to explicitly grant a >> permission, but an extremely common case, I think, will be to grant it >> by indicating a domain with a set of exceptions. > > > Authentication is not terribly important here, but rather the ease of > creating new identities within a domain. They are related. Because of authentication, creation of a new identity requires establishment of credentials for that identity. Since this needs to be handled by the domain administrator, it seems that it is much easier to manage these identities. > > Note, in particular, that the authenticated name in a SIMPLE context may > or may not correspond 1-1 to the From identifier. There is nothing that > prevents (or should prevent) allowing something like the foo+anything > mechanism, with a single login (Digest) identity. > > Thus, a user who wants to use blacklists reliably has to have a fairly > detailed understanding of the identity creation and authentication > policies in the domain. > > I'm not arguing that they will never work, just that they will often > fail in surprising ways. To me, this feels like throwing away the baby with the bathwater. Just because there will be domains with name allocation policies that make it easy to get new names, does not mean that a system should never support black lists. I believe that the need for authentication in these systems will go hand in hand with identity management which generally will make it hard to readily obtain new names (and in particular, new names with new credentials). Of course, there can be cases where this is not true. I'd rather deal with that using caveats in the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 8 11:33:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20075; Sat, 8 Nov 2003 11:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIW2H-0001CF-00; Sat, 08 Nov 2003 11:34:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIW2H-0001CA-00; Sat, 08 Nov 2003 11:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIW2C-0004BS-Px; Sat, 08 Nov 2003 11:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIW1g-0004Ap-Cc for simple@optimus.ietf.org; Sat, 08 Nov 2003 11:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20060; Sat, 8 Nov 2003 11:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIW1f-0001Bi-00; Sat, 08 Nov 2003 11:33:27 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIW1e-0001BX-00; Sat, 08 Nov 2003 11:33:26 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA8GWlhL024835; Sat, 8 Nov 2003 11:32:47 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA8GWlg14103; Sat, 8 Nov 2003 11:32:47 -0500 Message-ID: <3FAD1AAE.3040901@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: alex.audu@alcatel.com, Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> <3FAC81AE.4010905@dynamicsoft.com> In-Reply-To: <3FAC81AE.4010905@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 11:32:46 -0500 Content-Transfer-Encoding: 7bit > No one is saying that there is negative permissions here that can be > fetched by external reference. In particular, I am NOT proposing that The problem is that unless you put content-based restrictions on the external reference, they cannot contain exceptions, for the reasons noted below. > you can have a pure exception permission. Rather, a permission is always > additive, but merely defines the set of users that get added by > specifying a base plus a set of users to remove from that base. To be > concrete, I would agree that the set of users listed in any except > clauses *MUST* also be present in a non-except clause in the same > applies-to statement. This guarantees that the overall applies-to > statement is purely additive. This is indeed a useful additional restriction, but the problem is deeper than that. You also need to make sure that the same domain or userid does not appear in other rules. In GEOPRIV, the nice part of the rule model is that nothing breaks if you have the same URI appear multiple times. However, things get messy if you have to check for Rule set 1: applies to: columbia.edu except: alice Rule set 2 (by external reference from PIDF-LO): applies to: columbia.edu except: bob The merging of these gets rather messy, as you have to make sure that Rule 2 does not have a domain that also appears in Rule 1. You can define the mechanism so that rule sets 1 and 2 are individually additive, but try to explain to the user why Bob suddenly gets the more liberal permissions in rule set 1 after you've told the user that they can create blacklists. As I said before, having a single XML schema, except that rule set 2 cannot have exceptions, seems really confusing to users. Why should a perfectly fine rule set that worked ok when I XCAP-fed it to the PA/LS work, but be illegal if it's referenced from PIDF-LO? > > For example, a statement might look like: > > > example.com > > sip:user@example.com > > > > > > > This is an *additive* permission. It defines a set of users (everyone in > example.com but user) that now get these new permissions. If the above > statement cannot be obtained, those users won't get the specified > permissions. > > Based on my definitions, the following is NOT A LEGAL DOCUMENT: > > > example.com > > sip:user@foo.com > > > > Here, you would definitely have the problems you describe. I am agreeing > we should not allow this case. You know how much fun comparing SIP URIs is... While this is trivial for the simple ASCII examples that you have offered here, checking domain equality for exceptions would have to be very tightly circumscribed to be tractable. Should 'applies to columbia.edu except alice@cs.columbia.edu' be allowed? You now no longer have a simple equality match, but have to be far more precise as to what's allowed and what isn't. Also, this can no longer be readily expressed in anything approaching a database table. Internally, you would indeed have to create a separate exception table, along the lines that I have alluded to earlier since each row can only have one matching field (URI). I'm harping on the database issue not because I believe that every implementation will use them, but because they have precise matching semantics that we can describe rigorously. I would feel very uncomfortable with the reliability of this whole edifice if I can't write down a boolean query and know precisely what the outcome will be (and can encode this in the specification itself). > Agreed here on all points. Please see my above description. Hopefully > this clarifies that the proposed exception mechanism is not creating > negative permissions. This 'negative permissions' comment was not in relation to your proposal, but in response to what others have offered. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 8 11:34:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20126 for ; Sat, 8 Nov 2003 11:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIW2K-0004DV-Ix for simple-archive@odin.ietf.org; Sat, 08 Nov 2003 11:34:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8GY82j016205 for simple-archive@odin.ietf.org; Sat, 8 Nov 2003 11:34:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIW2K-0004DI-Fd for simple-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 11:34:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20075; Sat, 8 Nov 2003 11:33:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIW2H-0001CF-00; Sat, 08 Nov 2003 11:34:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIW2H-0001CA-00; Sat, 08 Nov 2003 11:34:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIW2C-0004BS-Px; Sat, 08 Nov 2003 11:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIW1g-0004Ap-Cc for simple@optimus.ietf.org; Sat, 08 Nov 2003 11:33:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20060; Sat, 8 Nov 2003 11:33:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIW1f-0001Bi-00; Sat, 08 Nov 2003 11:33:27 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIW1e-0001BX-00; Sat, 08 Nov 2003 11:33:26 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA8GWlhL024835; Sat, 8 Nov 2003 11:32:47 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA8GWlg14103; Sat, 8 Nov 2003 11:32:47 -0500 Message-ID: <3FAD1AAE.3040901@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: alex.audu@alcatel.com, Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> <3FAC81AE.4010905@dynamicsoft.com> In-Reply-To: <3FAC81AE.4010905@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 11:32:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > No one is saying that there is negative permissions here that can be > fetched by external reference. In particular, I am NOT proposing that The problem is that unless you put content-based restrictions on the external reference, they cannot contain exceptions, for the reasons noted below. > you can have a pure exception permission. Rather, a permission is always > additive, but merely defines the set of users that get added by > specifying a base plus a set of users to remove from that base. To be > concrete, I would agree that the set of users listed in any except > clauses *MUST* also be present in a non-except clause in the same > applies-to statement. This guarantees that the overall applies-to > statement is purely additive. This is indeed a useful additional restriction, but the problem is deeper than that. You also need to make sure that the same domain or userid does not appear in other rules. In GEOPRIV, the nice part of the rule model is that nothing breaks if you have the same URI appear multiple times. However, things get messy if you have to check for Rule set 1: applies to: columbia.edu except: alice Rule set 2 (by external reference from PIDF-LO): applies to: columbia.edu except: bob The merging of these gets rather messy, as you have to make sure that Rule 2 does not have a domain that also appears in Rule 1. You can define the mechanism so that rule sets 1 and 2 are individually additive, but try to explain to the user why Bob suddenly gets the more liberal permissions in rule set 1 after you've told the user that they can create blacklists. As I said before, having a single XML schema, except that rule set 2 cannot have exceptions, seems really confusing to users. Why should a perfectly fine rule set that worked ok when I XCAP-fed it to the PA/LS work, but be illegal if it's referenced from PIDF-LO? > > For example, a statement might look like: > > > example.com > > sip:user@example.com > > > > > > > This is an *additive* permission. It defines a set of users (everyone in > example.com but user) that now get these new permissions. If the above > statement cannot be obtained, those users won't get the specified > permissions. > > Based on my definitions, the following is NOT A LEGAL DOCUMENT: > > > example.com > > sip:user@foo.com > > > > Here, you would definitely have the problems you describe. I am agreeing > we should not allow this case. You know how much fun comparing SIP URIs is... While this is trivial for the simple ASCII examples that you have offered here, checking domain equality for exceptions would have to be very tightly circumscribed to be tractable. Should 'applies to columbia.edu except alice@cs.columbia.edu' be allowed? You now no longer have a simple equality match, but have to be far more precise as to what's allowed and what isn't. Also, this can no longer be readily expressed in anything approaching a database table. Internally, you would indeed have to create a separate exception table, along the lines that I have alluded to earlier since each row can only have one matching field (URI). I'm harping on the database issue not because I believe that every implementation will use them, but because they have precise matching semantics that we can describe rigorously. I would feel very uncomfortable with the reliability of this whole edifice if I can't write down a boolean query and know precisely what the outcome will be (and can encode this in the specification itself). > Agreed here on all points. Please see my above description. Hopefully > this clarifies that the proposed exception mechanism is not creating > negative permissions. This 'negative permissions' comment was not in relation to your proposal, but in response to what others have offered. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 8 11:49:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20563; Sat, 8 Nov 2003 11:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIWHp-0001Sy-00; Sat, 08 Nov 2003 11:50:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIWHo-0001Sv-00; Sat, 08 Nov 2003 11:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIWHi-0005HU-Ir; Sat, 08 Nov 2003 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIWH2-0005Gq-Da for simple@optimus.ietf.org; Sat, 08 Nov 2003 11:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20545; Sat, 8 Nov 2003 11:49:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIWH1-0001SP-00; Sat, 08 Nov 2003 11:49:19 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIWH0-0001SF-00; Sat, 08 Nov 2003 11:49:18 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA8GmOhL027831; Sat, 8 Nov 2003 11:48:24 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA8GmOg15472; Sat, 8 Nov 2003 11:48:24 -0500 Message-ID: <3FAD1E57.6090201@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> <3FAC6335.2020109@cs.columbia.edu> <3FAC8928.9040500@dynamicsoft.com> In-Reply-To: <3FAC8928.9040500@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 11:48:23 -0500 Content-Transfer-Encoding: 7bit > OK, I can agree to that, but again I dont see the need for a physically > separated listing. ALl you need to do is specify that the set of > elements in the exception list cannot be wildcarded. See previous message on related difficulties. > They are related. Because of authentication, creation of a new identity > requires establishment of credentials for that identity. Since this > needs to be handled by the domain administrator, it seems that it is > much easier to manage these identities. We have authenticated email submission, but users can submit email under an effectively infinite number of identities (related to their core identity). > > Just because there will be domains with name allocation policies that > make it easy to get new names, does not mean that a system should never > support black lists. I believe that the need for authentication in these > systems will go hand in hand with identity management which generally > will make it hard to readily obtain new names (and in particular, new > names with new credentials). Of course, there can be cases where this is > not true. I'd rather deal with that using caveats in the spec. I'm sure users and system administrators will read these caveats and act accordingly :-) For policy languages, my bias is towards being underpromising and overdelivering, rather than lulling users into a false sense of security (or, here, privacy). The more special cases there are, the more likely it is that users will have the wrong mental model of what's happening and thus make mistakes. From the discussion here, it's clear that it is taking even technically sophisticated protocol designers a while to work out all the cases that work and don't work. Thus, I'm trying to find the absolute minimum set of exceptions, rules, caveats, disclosures, warnings and algorithms. Things get complicated if you have multiple sources of policy, such as in the GEOPRIV reference + LS model (see the example where the same domain with different exceptions appears in multiple policy documents). After all, if you really need blacklists within a company and a simple "please don't subscribe to me" doesn't work, that pestering stalking colleague has an incentive to find ways to bypass your blacklist. We all agree, I hope, that the domain + exception model is useless for, say, aol.com. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 8 11:50:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20598 for ; Sat, 8 Nov 2003 11:50:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIWHr-0005L9-Qt for simple-archive@odin.ietf.org; Sat, 08 Nov 2003 11:50:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8GoBfc020521 for simple-archive@odin.ietf.org; Sat, 8 Nov 2003 11:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIWHr-0005Ku-Na for simple-web-archive@optimus.ietf.org; Sat, 08 Nov 2003 11:50:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20563; Sat, 8 Nov 2003 11:49:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIWHp-0001Sy-00; Sat, 08 Nov 2003 11:50:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIWHo-0001Sv-00; Sat, 08 Nov 2003 11:50:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIWHi-0005HU-Ir; Sat, 08 Nov 2003 11:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIWH2-0005Gq-Da for simple@optimus.ietf.org; Sat, 08 Nov 2003 11:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20545; Sat, 8 Nov 2003 11:49:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIWH1-0001SP-00; Sat, 08 Nov 2003 11:49:19 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIWH0-0001SF-00; Sat, 08 Nov 2003 11:49:18 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA8GmOhL027831; Sat, 8 Nov 2003 11:48:24 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA8GmOg15472; Sat, 8 Nov 2003 11:48:24 -0500 Message-ID: <3FAD1E57.6090201@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Andrew Newton , Naoko ITO , Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> <3FABA901.4040006@ecotroph.net> <3FABB2B9.3060003@cs.columbia.edu> <3FABFECE.4040606@dynamicsoft.com> <3FAC6335.2020109@cs.columbia.edu> <3FAC8928.9040500@dynamicsoft.com> In-Reply-To: <3FAC8928.9040500@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 08 Nov 2003 11:48:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > OK, I can agree to that, but again I dont see the need for a physically > separated listing. ALl you need to do is specify that the set of > elements in the exception list cannot be wildcarded. See previous message on related difficulties. > They are related. Because of authentication, creation of a new identity > requires establishment of credentials for that identity. Since this > needs to be handled by the domain administrator, it seems that it is > much easier to manage these identities. We have authenticated email submission, but users can submit email under an effectively infinite number of identities (related to their core identity). > > Just because there will be domains with name allocation policies that > make it easy to get new names, does not mean that a system should never > support black lists. I believe that the need for authentication in these > systems will go hand in hand with identity management which generally > will make it hard to readily obtain new names (and in particular, new > names with new credentials). Of course, there can be cases where this is > not true. I'd rather deal with that using caveats in the spec. I'm sure users and system administrators will read these caveats and act accordingly :-) For policy languages, my bias is towards being underpromising and overdelivering, rather than lulling users into a false sense of security (or, here, privacy). The more special cases there are, the more likely it is that users will have the wrong mental model of what's happening and thus make mistakes. From the discussion here, it's clear that it is taking even technically sophisticated protocol designers a while to work out all the cases that work and don't work. Thus, I'm trying to find the absolute minimum set of exceptions, rules, caveats, disclosures, warnings and algorithms. Things get complicated if you have multiple sources of policy, such as in the GEOPRIV reference + LS model (see the example where the same domain with different exceptions appears in multiple policy documents). After all, if you really need blacklists within a company and a simple "please don't subscribe to me" doesn't work, that pestering stalking colleague has an incentive to find ways to bypass your blacklist. We all agree, I hope, that the domain + exception model is useless for, say, aol.com. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Nov 9 10:32:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01775; Sun, 9 Nov 2003 10:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrYs-0002fQ-00; Sun, 09 Nov 2003 10:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrYr-0002fJ-00; Sun, 09 Nov 2003 10:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYj-0007UZ-GD; Sun, 09 Nov 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7YV-0008Kx-93 for simple@optimus.ietf.org; Fri, 07 Nov 2003 09:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15640; Fri, 7 Nov 2003 09:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7YT-0005iW-00; Fri, 07 Nov 2003 09:25:41 -0500 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1AI7YT-0005iQ-00; Fri, 07 Nov 2003 09:25:41 -0500 Received: from ecotroph.net ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Fri, 07 Nov 2003 09:25:39 -0500 Message-ID: <3FABA901.4040006@ecotroph.net> From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naoko ITO CC: Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> In-Reply-To: <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 09:15:29 -0500 Content-Transfer-Encoding: 7bit As I recall: at the interim meeting in September we were fortunate to have two people in attendance that had implemented similar access systems. It was their opinion that the 'except' clause adds enough processing to be a scalability concern for even moderately loaded systems. The fastest systems are able to take a set of rules and process them one after another until there is a hit. Naoko ITO wrote: > > I don't understand why the except clause in each permission statement > should be dismissed while the separate exception list model can be > supported. > > 1) introducing a separate exception list but not supporting it, > 2) introducing an except clause in each permission but not supporting > it. Neither do I. But in my opinion, both should be dismissed. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Nov 9 10:32:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01778; Sun, 9 Nov 2003 10:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrYs-0002fU-00; Sun, 09 Nov 2003 10:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrYr-0002fL-00; Sun, 09 Nov 2003 10:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYk-0007Uu-CH; Sun, 09 Nov 2003 10:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJPd-0002lR-Om for simple@optimus.ietf.org; Fri, 07 Nov 2003 22:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20207; Fri, 7 Nov 2003 22:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJPa-0007SZ-00; Fri, 07 Nov 2003 22:05:18 -0500 Received: from rcpt-expgw.biglobe.ne.jp ([202.225.89.175]) by ietf-mx with esmtp (Exim 4.12) id 1AIJPZ-0007SU-00; Fri, 07 Nov 2003 22:05:17 -0500 Received: from smtp-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (nkrw/1718140703) with ESMTP id hA835Ap20544; Sat, 8 Nov 2003 12:05:10 +0900 (JST) X-Biglobe-Sender: Received: from NAOVSR (218.221.84.207 [218.221.84.207]) by smtp-gw.biglobe.ne.jp id MAFMC0A82757; Sat, 08 Nov 2003 12:05:09 +0900 (JST) Reply-To: From: "Naoko ITO" To: "'Simple WG'" Cc: Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth Message-ID: <000001c3a5a5$1833a310$0300a8c0@NAOVSR> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3FABB3C6.1040605@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 8 Nov 2003 12:04:58 +0900 Content-Transfer-Encoding: 7bit Hello Henning, Thank you for your reply. Comments in-line. > It is not exactly a black list, although it can be used for that. > That's why I called it an exception list. Sorry, I was not (and am not) very careful about choosing words. I understand a black list is one of the application of exception list. > > Still, I'd like to have an except clause in a permission > statment as > > well, which can be used for a differenct purpose, i.e., giving > > different permissions to some groups of the watchers. > > I'm sorry to sound like a broken record: People requesting features > that break overall processing models should please have the kindness > to provide motivation beyond "it could be useful". As I didn't want to mix issues; WHY, WHAT and HOW, I sent out a separate note on this with a CUG example, which might not be convincing enough. Although I carelessly used the term 'black list' to simplify the explanation, it could be about any exception to a permission statement. > > In the case of Option #1, the rule enforcer should drop all the > > permission statements in the rule set in order to prevent those > > should-be-excepted watchers from accidentally obtaining > information, > > if there is an exception statement which cannot be > understood. i.e., > > no permission is granted to anybody at all. In the case of > Option #2, > > the rule enforcer should drop the permission statements > with unknown > > except clauses, which still allows some watchers to obtain > > information. It seems to me that both options give us the ways to > > ensure the privacy-safe even if the rule enforcer does not > support the > > except mechanism, and rather the latter is more elastic or > > fault-tolerant. Or is this just plausible? > > Please review the discussion on why this doesn't work when rules are > composed from multiple sources. Sorry about my lame explanations. The issues I tried to raise here are of the influence of introducing Capability A which is not supported by its rule enforcer X and of the forward compatibility as well. This will not be a problem if the rule enforcer supports an exception capability, but I was caught by the statement: "GEOPRIV might then decide not to support the exception list type, but the regular list type would be compatible." It will make all the permission statements useless to introduce a separate exception list which is not supported by its rule enforcer unless the privacy-safe policy is broken, which should be rather a problem. If it exists in a rule set, not only a separate exception list but an entire rule set needs to be dropped. Otherwise those listed people will never be excluded once they are granted by other permission statements. Then, suppose this exception list is one of the extenstion to the core xcap-auth and belongs to a different namespace. If this exception clause is separated from the normal permission, the rule enforcers without its support should - ignore the entire rule set, * which requires the knowledge about this particular extension, or * disallowing any extension at all, which is not forward compatible, OR - ignore the unknown elements, * which will violate the privacy, as the remaining If exception clauses are attached to permission statements, on the other hand, the privacy-safe mechanism mentioned in section 4.4 of geopriv-policy will work and some of the rule set will survive, as only the permission statements with unknown exception elements can be dropped. I believe the except clause in a permission statement is rather privacy-safe without giving up the entire rule set, while I think a separate extension list is more readable in some cases. Regards, ----- Naoko ITO / NEC _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 9 10:33:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01828 for ; Sun, 9 Nov 2003 10:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYw-0007Wq-Ev for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 10:33:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9FXEiG028934 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 10:33:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYw-0007Wb-Bc for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 10:33:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01775; Sun, 9 Nov 2003 10:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrYs-0002fQ-00; Sun, 09 Nov 2003 10:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrYr-0002fJ-00; Sun, 09 Nov 2003 10:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYj-0007UZ-GD; Sun, 09 Nov 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7YV-0008Kx-93 for simple@optimus.ietf.org; Fri, 07 Nov 2003 09:25:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15640; Fri, 7 Nov 2003 09:25:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7YT-0005iW-00; Fri, 07 Nov 2003 09:25:41 -0500 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1AI7YT-0005iQ-00; Fri, 07 Nov 2003 09:25:41 -0500 Received: from ecotroph.net ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Fri, 07 Nov 2003 09:25:39 -0500 Message-ID: <3FABA901.4040006@ecotroph.net> From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Naoko ITO CC: Simple WG , geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> In-Reply-To: <004801c3a502$07b361e0$52e2110a@lab5.netlab.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 09:15:29 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As I recall: at the interim meeting in September we were fortunate to have two people in attendance that had implemented similar access systems. It was their opinion that the 'except' clause adds enough processing to be a scalability concern for even moderately loaded systems. The fastest systems are able to take a set of rules and process them one after another until there is a hit. Naoko ITO wrote: > > I don't understand why the except clause in each permission statement > should be dismissed while the separate exception list model can be > supported. > > 1) introducing a separate exception list but not supporting it, > 2) introducing an except clause in each permission but not supporting > it. Neither do I. But in my opinion, both should be dismissed. -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 9 10:33:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01838 for ; Sun, 9 Nov 2003 10:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYx-0007ac-DX for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 10:33:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9FXF4N029165 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 10:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYx-0007a6-6a for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 10:33:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01778; Sun, 9 Nov 2003 10:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrYs-0002fU-00; Sun, 09 Nov 2003 10:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrYr-0002fL-00; Sun, 09 Nov 2003 10:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYk-0007Uu-CH; Sun, 09 Nov 2003 10:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJPd-0002lR-Om for simple@optimus.ietf.org; Fri, 07 Nov 2003 22:05:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20207; Fri, 7 Nov 2003 22:05:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJPa-0007SZ-00; Fri, 07 Nov 2003 22:05:18 -0500 Received: from rcpt-expgw.biglobe.ne.jp ([202.225.89.175]) by ietf-mx with esmtp (Exim 4.12) id 1AIJPZ-0007SU-00; Fri, 07 Nov 2003 22:05:17 -0500 Received: from smtp-gw.biglobe.ne.jp by rcpt-expgw.biglobe.ne.jp (nkrw/1718140703) with ESMTP id hA835Ap20544; Sat, 8 Nov 2003 12:05:10 +0900 (JST) X-Biglobe-Sender: Received: from NAOVSR (218.221.84.207 [218.221.84.207]) by smtp-gw.biglobe.ne.jp id MAFMC0A82757; Sat, 08 Nov 2003 12:05:09 +0900 (JST) Reply-To: From: "Naoko ITO" To: "'Simple WG'" Cc: Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth Message-ID: <000001c3a5a5$1833a310$0300a8c0@NAOVSR> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3FABB3C6.1040605@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 8 Nov 2003 12:04:58 +0900 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Henning, Thank you for your reply. Comments in-line. > It is not exactly a black list, although it can be used for that. > That's why I called it an exception list. Sorry, I was not (and am not) very careful about choosing words. I understand a black list is one of the application of exception list. > > Still, I'd like to have an except clause in a permission > statment as > > well, which can be used for a differenct purpose, i.e., giving > > different permissions to some groups of the watchers. > > I'm sorry to sound like a broken record: People requesting features > that break overall processing models should please have the kindness > to provide motivation beyond "it could be useful". As I didn't want to mix issues; WHY, WHAT and HOW, I sent out a separate note on this with a CUG example, which might not be convincing enough. Although I carelessly used the term 'black list' to simplify the explanation, it could be about any exception to a permission statement. > > In the case of Option #1, the rule enforcer should drop all the > > permission statements in the rule set in order to prevent those > > should-be-excepted watchers from accidentally obtaining > information, > > if there is an exception statement which cannot be > understood. i.e., > > no permission is granted to anybody at all. In the case of > Option #2, > > the rule enforcer should drop the permission statements > with unknown > > except clauses, which still allows some watchers to obtain > > information. It seems to me that both options give us the ways to > > ensure the privacy-safe even if the rule enforcer does not > support the > > except mechanism, and rather the latter is more elastic or > > fault-tolerant. Or is this just plausible? > > Please review the discussion on why this doesn't work when rules are > composed from multiple sources. Sorry about my lame explanations. The issues I tried to raise here are of the influence of introducing Capability A which is not supported by its rule enforcer X and of the forward compatibility as well. This will not be a problem if the rule enforcer supports an exception capability, but I was caught by the statement: "GEOPRIV might then decide not to support the exception list type, but the regular list type would be compatible." It will make all the permission statements useless to introduce a separate exception list which is not supported by its rule enforcer unless the privacy-safe policy is broken, which should be rather a problem. If it exists in a rule set, not only a separate exception list but an entire rule set needs to be dropped. Otherwise those listed people will never be excluded once they are granted by other permission statements. Then, suppose this exception list is one of the extenstion to the core xcap-auth and belongs to a different namespace. If this exception clause is separated from the normal permission, the rule enforcers without its support should - ignore the entire rule set, * which requires the knowledge about this particular extension, or * disallowing any extension at all, which is not forward compatible, OR - ignore the unknown elements, * which will violate the privacy, as the remaining If exception clauses are attached to permission statements, on the other hand, the privacy-safe mechanism mentioned in section 4.4 of geopriv-policy will work and some of the rule set will survive, as only the permission statements with unknown exception elements can be dropped. I believe the except clause in a permission statement is rather privacy-safe without giving up the entire rule set, while I think a separate extension list is more readable in some cases. Regards, ----- Naoko ITO / NEC _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 9 10:33:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01860 for ; Sun, 9 Nov 2003 10:33:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYx-0007aR-Ak for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 10:33:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9FXFH2029151 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 10:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYx-0007a5-5d for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 10:33:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01776; Sun, 9 Nov 2003 10:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrYs-0002fR-00; Sun, 09 Nov 2003 10:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrYr-0002fK-00; Sun, 09 Nov 2003 10:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYj-0007Uh-SN; Sun, 09 Nov 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7cW-0008R5-IA for simple@optimus.ietf.org; Fri, 07 Nov 2003 09:29:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15733; Fri, 7 Nov 2003 09:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7cU-0005kz-00; Fri, 07 Nov 2003 09:29:50 -0500 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1AI7cU-0005kw-00; Fri, 07 Nov 2003 09:29:50 -0500 Received: from ecotroph.net ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Fri, 07 Nov 2003 09:29:48 -0500 Message-ID: <3FABA9FA.6010008@ecotroph.net> From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tschofenig Hannes , Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> In-Reply-To: <3FAA9BD7.9070709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 09:19:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > dynamicsoft.com > > joe@dynamicsoft.com > bob@dynamicsoft.com > > > > > Where is the complexity here? What is wrong with using group roles with the syntax specified in the draft? Such as: mailto:support-staff@example.com ... -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Nov 9 11:22:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01776; Sun, 9 Nov 2003 10:32:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIrYs-0002fR-00; Sun, 09 Nov 2003 10:33:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIrYr-0002fK-00; Sun, 09 Nov 2003 10:33:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIrYj-0007Uh-SN; Sun, 09 Nov 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7cW-0008R5-IA for simple@optimus.ietf.org; Fri, 07 Nov 2003 09:29:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15733; Fri, 7 Nov 2003 09:29:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7cU-0005kz-00; Fri, 07 Nov 2003 09:29:50 -0500 Received: from zak.ecotroph.net ([216.93.164.123]) by ietf-mx with esmtp (Exim 4.12) id 1AI7cU-0005kw-00; Fri, 07 Nov 2003 09:29:50 -0500 Received: from ecotroph.net ([::ffff:64.83.8.178]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Fri, 07 Nov 2003 09:29:48 -0500 Message-ID: <3FABA9FA.6010008@ecotroph.net> From: Andrew Newton User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tschofenig Hannes , Henning Schulzrinne , "'Rosen, Brian'" , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> In-Reply-To: <3FAA9BD7.9070709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 07 Nov 2003 09:19:38 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > dynamicsoft.com > > joe@dynamicsoft.com > bob@dynamicsoft.com > > > > > Where is the complexity here? What is wrong with using group roles with the syntax specified in the draft? Such as: mailto:support-staff@example.com ... -andy _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Nov 9 13:15:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05202; Sun, 9 Nov 2003 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mr-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mc-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5Y-0004sQ-73; Sun, 09 Nov 2003 13:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu4o-0004rY-CC for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:14:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05176 for ; Sun, 9 Nov 2003 13:14:03 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4m-0004mJ-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:16 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4l-0004mG-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:15 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IEEe09075 for ; Sun, 9 Nov 2003 20:14:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:14:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 20:14:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Knowing which tuples to select Message-ID: Thread-Topic: [Simple] Knowing which tuples to select Thread-Index: AcOe+t1OuRkTg2FnRHmgHW9S/ZVBmgH01daA To: , X-OriginalArrivalTime: 09 Nov 2003 18:14:14.0087 (UTC) FILETIME=[47EFE570:01C3A6ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 20:14:13 +0200 Content-Transfer-Encoding: quoted-printable Hi Jonathan, See inline. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 30 October, 2003 17:30 > To: Simple WG > Subject: [Simple] Knowing which tuples to select >=20 >=20 > Folks, >=20 > As I mentioned in a previous note, per list discussion I removed=20 > transformational permissions from xcap-auth. Instead of havgin the=20 > xcap server apply the transformations, the idea proposed by Henning=20 > and others is to have a separate "application" in the network publish=20 > tuples for me that contain whatever information I wish to distribute.=20 > Indeed, the application itself might live in the endpoint as well. >=20 I'm not sure I follow the "application in a network" idea wrt. what I = thought transformational permissions vs. default/hard state publishing = were trying to address. I have two use cases: 1.) - I want to tell X that I'm in a meeting=20 - I want to tell Y that I'm in a bar In this case I can publish two tuples and authorize one of them to X and = the other to Y. The main concern I currently have is that xcap-auth only = allows to select tuples based on . At least I have intended to = use for instance so that it defines that a tuple is generated by = a certain type of application, so it makes easy for a similar = application to filter it. Now we would need to overload class for = authorization selections too. 2.) I want that my presence data _always_ includes my e-mail address and = homepage. I don't want to use SIP PUBLISH to maintain this type of "hard = state". For this I have proposed to define an XCAP application usage for = presence publishing. =20 So could you (or Henning explain) whether there is something beyond = these two cases we want to support that transformational permissions = were related to. Not related to transformation permissions (or perhaps I don't remember = their whole concept), there is clealy a third issue, which needs some = attention and seems to be the one discussed below. This is that what if = the presence agent really has some sources in the "network" that publish = presence information (this can be circuit switched call state, network = provided location information, whatever). The user should be able to = somehow authorize this information from his separate "endpoint".=20 > THere are still some open questions about achieving interoperability=20 > in such an environment, particularly if the application lives in the=20 > network: >=20 > * how does the user configure the behavior of this application? I=20 > think this is out of scope; we are not going to try and provide=20 > standardized interfaces for this control - thats the whole idea. >=20 > * assuming the user controls the application somehow, it will begin=20 > publishing tuples. How does the client know the RPID class of those=20 > tuples, so that it can control their distribution via xcap? >=20 >=20 > I see only a few choices for the second issue: >=20 > * ignore the problem - presumably the application will tell the user=20 > through some kind of UI which class to select >=20 > * agree on a standardized naming convention for tuples published by=20 > such applications >=20 > * treat this as a configuration problem. The device needs to be=20 > configured with RPID class corresponding to tuples published by=20 > applications. In that case, we might be able to place this data into=20 > xcap itself, so that it can be read by the client device. This would=20 > presumably be a separate application usage. >=20 >=20 > I'm inclined to go for the third option. >=20 I support this too. In any case, interoperability will require some = specification work not currently available. > Thoughts? >=20 > -Jonathan R. >=20 >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Nov 9 13:15:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05203; Sun, 9 Nov 2003 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mq-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mb-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5W-0004s4-LB; Sun, 09 Nov 2003 13:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu4a-0004rK-2K for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05169; Sun, 9 Nov 2003 13:13:48 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4X-0004m7-00; Sun, 09 Nov 2003 13:14:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4W-0004m2-00; Sun, 09 Nov 2003 13:14:01 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IDxe08903; Sun, 9 Nov 2003 20:13:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:13:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 20:13:57 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 20:13:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Geopriv] RE: [Simple] Changes in xcap-auth Message-ID: Thread-Topic: [Geopriv] RE: [Simple] Changes in xcap-auth Thread-Index: AcOlcBUfBxdthOUzTvCAqtdFH0QNiABVwQuA To: , Cc: , , , X-OriginalArrivalTime: 09 Nov 2003 18:13:57.0481 (UTC) FILETIME=[3E0A0590:01C3A6ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 20:13:56 +0200 Content-Transfer-Encoding: quoted-printable Hi, I've followed this thread from SIMPLE WG point of view. I agree mostly = with what Jonathan is writing below. I summarize my main points here: - In many "domains" (run by corporates, ISPs, operators) it is not = possible to ad hoc create new identities, and in any case authentication = is always required when an identity is used. This means that getting = around "black lists" is not as trivial as in e-mail.=20 - I agree that the usefulness of exceptions depends on how "group" = information is structured. In many cases, especially in corporates, = people use groups/lists that they themselves are not able to manage (and = in some cases not even see their content). This happens with e-mail, = calendars etc. I believe similar shared groups to be useful for = hobby-clubs, families etc. too. In those cases it is important to be = able to disclude some members by doing exceptions, e.g. "golf-club-list = EXCEPT Joe" or "engineering-department-list EXCEPT my boss". I = understood Ted's point that UI and protocol can be separated, but I = share Jonathan's concern below. - I didn't quite get why we couldn't define the and = so that if the part for some reason (external = reference etc.) could not be properly resolved, the whole = would result in empty set, i.e. at least no leaks would be introduced. - Also I did't get what was wrong with Ted's proposal to define a = separate element. To me that would be OK as = well. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 07 November, 2003 22:22 > To: Henning Schulzrinne > Cc: Andrew Newton; Naoko ITO; Simple WG; geopriv@ietf.org > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth >=20 >=20 > inline. >=20 > Henning Schulzrinne wrote: >=20 > >>> I don't understand why the except clause in each permission > >>> statement should be dismissed while the separate exception list > >>> model can be supported. > >=20 > >=20 > > The exception list is restricted in its functionality to avoid the > > privacy problems caused by exception entries. Mixing the two means > > that both list types would need to be restricted as described. > >=20 > > Also, having unbounded except lists makes processing more > > complicated since the simple row model no longer applies (it's no > > longer a relational table). >=20 > I share Ito-san's confusion here. Assuming the same kind of > restrictions you have asked for - no external references, no > wildcards, no domain-scopes, I dont see the difference between: >=20 > > example.com > > joe@example.com > > >=20 > and: >=20 > > example.com > >=20 > > joe@example.com > >=20 > THe differences seem merely syntactic, but maybe I am missing > something here. >=20 > Henning also wrote: > > Blacklists were popular for spam-protection early on, but I think > > everyone has realized by now that they are close to useless. I'd > > hate to create a complicated, brittle, difficult-to-predict system > > just to find out a year later that this expensive feature turned > > out to be mostly an empty promise, in terms of increasing user > > privacy. >=20 > There are some serious differences here with the email spam case.=20 > Firstly, the systems we are talking about require authentication,=20 > which is absent in email. Secondly, and perhaps most=20 > importantly, I am=20 > not interested in rules like "allow anyone in the world but=20 > bob@example.com", as I agree this is silly. We are talking=20 > about rules=20 > like "allow only people from example.com EXCEPT=20 > bob@example.com". That=20 > is, I expect these systems to require a user to explicitly grant a=20 > permission, but an extremely common case, I think, will be to=20 > grant it=20 > by indicating a domain with a set of exceptions. >=20 > Ted wrote: > > To take up your point on implementation, I note that > > folks do seem to be assuming a connection between > > the UI and the protocol behavior. I can easily see > > a UI saying "Grant all buddies civil geolocation data > > at City level, except $ex-spouse, who should get > > my timezone" and translating that as a grant of > > timezone to all buddies and a second grant of > > City to each of those that isn't the ex-spouse. From > > the user point of view, it's an "except", where from the > > protocol point of view it is additive permissions. > >=20 > > There is no question that there are engineering trade-offs here. > > You gain simplicity and have an easy method to > > ensure maximal privacy, but you may get increased > > object size and you may need to structure group data > > in ways that ensure it fits this model reasonably > > efficiently. Neither choice is perfect, but this one > > does have some very useful characteristics for a > > large number of GeoPriv cases. There may be other > > usage patterns in other uses of XCAP that mean > > we can't have a perfect fit, but if we can keep that > > split to a minimum, I think it's worth it. >=20 > To summarize (correct me if I am wrong), I think your suggestion was=20 > that exceptions can be handled by expanding the lists associated with=20 > the domain. As such, even though the user sees an exception rule in=20 > the UI, the underlying system pushes a permission with everyone in it. >=20 > My concern is that I believe this will be very difficult to=20 > manage. It=20 > requires the users to have access to the set of users in the domain=20 > from which the exceptions are being specified. That list is=20 > undoubtedly dynamic, and potentially pretty large. When a new=20 > employee=20 > joins the company, everyone would have to update their=20 > permissiosn (or=20 > have their agents do it automatically somehow), and similarly when=20 > someone leaves. The result will be odd behavior for users, where=20 > people that a user believes to have permission, actually doesnt. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 exim@www1.ietf.org Sun Nov 9 13:15:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05260 for ; Sun, 9 Nov 2003 13:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5k-0004uc-9V for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 13:15:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9IFGE8018876 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 13:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5k-0004uN-5q for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05202; Sun, 9 Nov 2003 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mr-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mc-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5Y-0004sQ-73; Sun, 09 Nov 2003 13:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu4o-0004rY-CC for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:14:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05176 for ; Sun, 9 Nov 2003 13:14:03 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4m-0004mJ-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:16 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4l-0004mG-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:15 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IEEe09075 for ; Sun, 9 Nov 2003 20:14:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:14:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 20:14:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Knowing which tuples to select Message-ID: Thread-Topic: [Simple] Knowing which tuples to select Thread-Index: AcOe+t1OuRkTg2FnRHmgHW9S/ZVBmgH01daA To: , X-OriginalArrivalTime: 09 Nov 2003 18:14:14.0087 (UTC) FILETIME=[47EFE570:01C3A6ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 20:14:13 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, See inline. > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 30 October, 2003 17:30 > To: Simple WG > Subject: [Simple] Knowing which tuples to select >=20 >=20 > Folks, >=20 > As I mentioned in a previous note, per list discussion I removed=20 > transformational permissions from xcap-auth. Instead of havgin the=20 > xcap server apply the transformations, the idea proposed by Henning=20 > and others is to have a separate "application" in the network publish=20 > tuples for me that contain whatever information I wish to distribute.=20 > Indeed, the application itself might live in the endpoint as well. >=20 I'm not sure I follow the "application in a network" idea wrt. what I = thought transformational permissions vs. default/hard state publishing = were trying to address. I have two use cases: 1.) - I want to tell X that I'm in a meeting=20 - I want to tell Y that I'm in a bar In this case I can publish two tuples and authorize one of them to X and = the other to Y. The main concern I currently have is that xcap-auth only = allows to select tuples based on . At least I have intended to = use for instance so that it defines that a tuple is generated by = a certain type of application, so it makes easy for a similar = application to filter it. Now we would need to overload class for = authorization selections too. 2.) I want that my presence data _always_ includes my e-mail address and = homepage. I don't want to use SIP PUBLISH to maintain this type of "hard = state". For this I have proposed to define an XCAP application usage for = presence publishing. =20 So could you (or Henning explain) whether there is something beyond = these two cases we want to support that transformational permissions = were related to. Not related to transformation permissions (or perhaps I don't remember = their whole concept), there is clealy a third issue, which needs some = attention and seems to be the one discussed below. This is that what if = the presence agent really has some sources in the "network" that publish = presence information (this can be circuit switched call state, network = provided location information, whatever). The user should be able to = somehow authorize this information from his separate "endpoint".=20 > THere are still some open questions about achieving interoperability=20 > in such an environment, particularly if the application lives in the=20 > network: >=20 > * how does the user configure the behavior of this application? I=20 > think this is out of scope; we are not going to try and provide=20 > standardized interfaces for this control - thats the whole idea. >=20 > * assuming the user controls the application somehow, it will begin=20 > publishing tuples. How does the client know the RPID class of those=20 > tuples, so that it can control their distribution via xcap? >=20 >=20 > I see only a few choices for the second issue: >=20 > * ignore the problem - presumably the application will tell the user=20 > through some kind of UI which class to select >=20 > * agree on a standardized naming convention for tuples published by=20 > such applications >=20 > * treat this as a configuration problem. The device needs to be=20 > configured with RPID class corresponding to tuples published by=20 > applications. In that case, we might be able to place this data into=20 > xcap itself, so that it can be read by the client device. This would=20 > presumably be a separate application usage. >=20 >=20 > I'm inclined to go for the third option. >=20 I support this too. In any case, interoperability will require some = specification work not currently available. > Thoughts? >=20 > -Jonathan R. >=20 >=20 >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 9 13:15:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05268 for ; Sun, 9 Nov 2003 13:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5k-0004uJ-4L for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 13:15:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9IFGrR018860 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 13:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5j-0004u7-Uq for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:15:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05199; Sun, 9 Nov 2003 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004ml-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu5f-0004ma-00; Sun, 09 Nov 2003 13:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5X-0004sI-L7; Sun, 09 Nov 2003 13:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu4g-0004rT-6s for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:14:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05173 for ; Sun, 9 Nov 2003 13:13:55 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4e-0004mD-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4d-0004mA-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:07 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IE6e08973 for ; Sun, 9 Nov 2003 20:14:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:14:05 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 20:14:04 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 20:14:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Questions on XCAP Usage for Authorization Message-ID: Thread-Topic: [Simple] Questions on XCAP Usage for Authorization Thread-Index: AcOf6b8zMihRfp+vR++EmP1IKG5GlQG42Row To: , Cc: X-OriginalArrivalTime: 09 Nov 2003 18:14:04.0480 (UTC) FILETIME=[4235FC00:01C3A6ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 20:14:04 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Jonathan Rosenberg replies to Naoko Ito: > > - Is there any way to reject a watcher who is given permissions by > > other statements? > > ex) Give a permission to any user whose domain is=20 > "example.com" but > > Joe. >=20 > Yes, now that is possible in -01. You would define a statement that=20 > allows anyone but Joe: >=20 > > > example.com > > sip:joe@example.com > > >=20 > > >=20 > and to reject Joe, there would be this statement: >=20 > > > sip:joe@example.com > > >=20 > Note how, in the second statement, there is an applies-to, but *no*=20 > permissions. I.e., the way to reject someone is that they are granted=20 > no permissions. If the default is that no-one is granted no permissions, what is the = difference the second statement makes? Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 31 October, 2003 22:00 > To: Naoko ITO > Cc: simple@ietf.org > Subject: Re: [Simple] Questions on XCAP Usage for Authorization >=20 >=20 > Sorry for the delay in responding. Answers inline. >=20 > Naoko ITO wrote: >=20 > > Hello, > >=20 > > I have some questions on XCAP Usage for Authorization. > >=20 > > The draft says, > > The overall authorization for a watcher is represented=20 > by the union > > of the permissions granted to that watcher. > > and > > In that case, the union of the permissions across those=20 > statements > > is applied to the subscription. > >=20 > > Am I correctly understanding that the overall authorization is > > determined by simply putting together every permission related to a > > specific watcher? >=20 > Yes. >=20 > >=20 > > Then, some questions occur to me. > >=20 > > - Is there any way to reject a watcher who is given permissions by > > other statements? > > ex) Give a permission to any user whose domain is=20 > "example.com" but > > Joe. >=20 > Yes, now that is possible in -01. You would define a statement that=20 > allows anyone but Joe: >=20 > > > example.com > > sip:joe@example.com > > >=20 > > >=20 > and to reject Joe, there would be this statement: >=20 > > > sip:joe@example.com > > >=20 > Note how, in the second statement, there is an applies-to, but *no*=20 > permissions. I.e., the way to reject someone is that they are granted=20 > no permissions. >=20 >=20 > > - Is there a way to have a default policy which can be overridden by > > other statements? It seems possible to reject, or not to give a > > permission to all the watchers by default and add permisions to > > specific users only. But it does not seem possible to accept every > > user by default unless listed on a black list. >=20 > Sure, you can do that. You would have two-statements: >=20 > > > > > http://xcap.example.com/resource-lists/users/joe/ > black-list > > >=20 > > >=20 > > > http://xcap.example.com/resource-lists/users/joe/ > black-list > > >=20 > This is now possible because of the except clause which I=20 > added in -01. >=20 >=20 > > - How to solve the conflicts between two or more=20 > permissions related to > > one watcher? >=20 > Ahh, thats the whole idea. >=20 > There *can't* be conflicts. By defining the permissions as additive=20 > always, you never have conflicts. Geopriv has taken the exact same=20 > approach. >=20 >=20 > >=20 > > I understand this is still under discussion, as it says, > >=20 > > OPEN ISSUE: Another model is that you take permissions for the > > most specific match. I think union makes more sense=20 > in the model > > where the entries in the statement are permissions. > >=20 > > but it'd be greatful if I can be provided any idea on this. >=20 > I think we've concluded here. I believe that the appropriate model is=20 > as specified. With the addition of the except clause, I am confident=20 > that we can easily specify a wide range of things, and furthermore,=20 > have a model which always maximizes privacy. You never have to worry=20 > about information being given out by accident because some blocking=20 > rule was overriden with a permission rule. People only get=20 > information=20 > when they are granted an explicit permission. >=20 > Given that geopriv has also chosen this model, its clear to me that=20 > its the right way to go. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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-admin@ietf.org Sun Nov 9 13:47:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06260; Sun, 9 Nov 2003 13:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIubW-0005ON-00; Sun, 09 Nov 2003 13:48:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIubW-0005OK-00; Sun, 09 Nov 2003 13:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIubQ-0007OU-7K; Sun, 09 Nov 2003 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuaa-0007NK-1j for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06209; Sun, 9 Nov 2003 13:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuaX-0005Mu-00; Sun, 09 Nov 2003 13:47:05 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIuaX-0005Mh-00; Sun, 09 Nov 2003 13:47:05 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA9IkHhL005615; Sun, 9 Nov 2003 13:46:17 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA9Ik4f26443; Sun, 9 Nov 2003 13:46:05 -0500 Message-ID: <3FAE8B6A.7070101@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Nov 2003 13:46:02 -0500 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > I've followed this thread from SIMPLE WG point of view. I agree > mostly with what Jonathan is writing below. I summarize my main > points here: - In many "domains" (run by corporates, ISPs, operators) > it is not possible to ad hoc create new identities, and in any case > authentication is always required when an identity is used. This > means that getting around "black lists" is not as trivial as in > e-mail. As I pointed out before, authentication does not guarantee uniqueness or difficulty in acquiring new identities. In any event, it's pure speculation at this point where and how easy it will be for users to acquire new identities, so there's probably not much point in continuing that particular thread. - I agree that the usefulness of exceptions depends on how > "group" information is structured. In many cases, especially in > corporates, people use groups/lists that they themselves are not able > to manage (and in some cases not even see their content). This > happens with e-mail, calendars etc. I believe similar shared groups > to be useful for hobby-clubs, families etc. too. In those cases it is > important to be able to disclude some members by doing exceptions, > e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list > EXCEPT my boss". I understood Ted's point that UI and protocol can be > separated, but I share Jonathan's concern below. These types of groups are rather different from identities as there is no way for a user to log in as 'member of bowling team'. Thus, I think it would be confusing to treat them just like another identifier. Whether to allow matching on group membership is another matter, but it would likely be a separate 'column'. The problem with groups is that there is no unique way to check for group membership in general. There is also no global namespace for them, so that there is no guarantee that two servers that see a rule set reference will make the same determination. (We obviously have email lists and maybe even SIP replication lists and buddy lists, but they are unresolvable outside a very narrow context.) - I didn't quite get > why we couldn't define the and so that if > the part for some reason (external reference etc.) could > not be properly resolved, the whole would result in > empty set, i.e. at least no leaks would be introduced. - Also I did't > get what was wrong with Ted's proposal to define a separate > element. To me that would be OK as well. > I don't think we're all that far apart. Since assumptions are rather important in this whole discussion, let me state my current view of what can and cannot be done. - Each rule must have the exceptions atomically encoded in the same rule, i.e., the rule cannot refer to exceptions elsewhere. The exceptions simply restrict the cases where the rule matches. In other words, exceptions within rule A do not influence the behavior of rule B. - Some systems will have multiple rulesets, e.g., one stored at the server and one carried by the location update. In general, we need to be sure that it is clear what happens in cases such as Rule 1: example.com except alice@example.com Rule 2: example.com except bob@example.com In the additive model, Bob will get the permissions in Rule 1. This may or may not be what users want. (If people are happy with that, I think we can make that work.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 9 13:48:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06305 for ; Sun, 9 Nov 2003 13:48:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuba-0007Ru-1w for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 13:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9ImANT028628 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 13:48:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIubZ-0007Rf-Uk for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:48:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06260; Sun, 9 Nov 2003 13:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIubW-0005ON-00; Sun, 09 Nov 2003 13:48:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIubW-0005OK-00; Sun, 09 Nov 2003 13:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIubQ-0007OU-7K; Sun, 09 Nov 2003 13:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIuaa-0007NK-1j for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06209; Sun, 9 Nov 2003 13:46:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIuaX-0005Mu-00; Sun, 09 Nov 2003 13:47:05 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIuaX-0005Mh-00; Sun, 09 Nov 2003 13:47:05 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA9IkHhL005615; Sun, 9 Nov 2003 13:46:17 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA9Ik4f26443; Sun, 9 Nov 2003 13:46:05 -0500 Message-ID: <3FAE8B6A.7070101@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Nov 2003 13:46:02 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > I've followed this thread from SIMPLE WG point of view. I agree > mostly with what Jonathan is writing below. I summarize my main > points here: - In many "domains" (run by corporates, ISPs, operators) > it is not possible to ad hoc create new identities, and in any case > authentication is always required when an identity is used. This > means that getting around "black lists" is not as trivial as in > e-mail. As I pointed out before, authentication does not guarantee uniqueness or difficulty in acquiring new identities. In any event, it's pure speculation at this point where and how easy it will be for users to acquire new identities, so there's probably not much point in continuing that particular thread. - I agree that the usefulness of exceptions depends on how > "group" information is structured. In many cases, especially in > corporates, people use groups/lists that they themselves are not able > to manage (and in some cases not even see their content). This > happens with e-mail, calendars etc. I believe similar shared groups > to be useful for hobby-clubs, families etc. too. In those cases it is > important to be able to disclude some members by doing exceptions, > e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list > EXCEPT my boss". I understood Ted's point that UI and protocol can be > separated, but I share Jonathan's concern below. These types of groups are rather different from identities as there is no way for a user to log in as 'member of bowling team'. Thus, I think it would be confusing to treat them just like another identifier. Whether to allow matching on group membership is another matter, but it would likely be a separate 'column'. The problem with groups is that there is no unique way to check for group membership in general. There is also no global namespace for them, so that there is no guarantee that two servers that see a rule set reference will make the same determination. (We obviously have email lists and maybe even SIP replication lists and buddy lists, but they are unresolvable outside a very narrow context.) - I didn't quite get > why we couldn't define the and so that if > the part for some reason (external reference etc.) could > not be properly resolved, the whole would result in > empty set, i.e. at least no leaks would be introduced. - Also I did't > get what was wrong with Ted's proposal to define a separate > element. To me that would be OK as well. > I don't think we're all that far apart. Since assumptions are rather important in this whole discussion, let me state my current view of what can and cannot be done. - Each rule must have the exceptions atomically encoded in the same rule, i.e., the rule cannot refer to exceptions elsewhere. The exceptions simply restrict the cases where the rule matches. In other words, exceptions within rule A do not influence the behavior of rule B. - Some systems will have multiple rulesets, e.g., one stored at the server and one carried by the location update. In general, we need to be sure that it is clear what happens in cases such as Rule 1: example.com except alice@example.com Rule 2: example.com except bob@example.com In the additive model, Bob will get the permissions in Rule 1. This may or may not be what users want. (If people are happy with that, I think we can make that work.) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 9 14:04:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05269 for ; Sun, 9 Nov 2003 13:15:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5k-0004uu-Le for simple-archive@odin.ietf.org; Sun, 09 Nov 2003 13:15:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA9IFGZ8018894 for simple-archive@odin.ietf.org; Sun, 9 Nov 2003 13:15:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5k-0004uf-I8 for simple-web-archive@optimus.ietf.org; Sun, 09 Nov 2003 13:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05203; Sun, 9 Nov 2003 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mq-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004mb-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5W-0004s4-LB; Sun, 09 Nov 2003 13:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu4a-0004rK-2K for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05169; Sun, 9 Nov 2003 13:13:48 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4X-0004m7-00; Sun, 09 Nov 2003 13:14:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4W-0004m2-00; Sun, 09 Nov 2003 13:14:01 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IDxe08903; Sun, 9 Nov 2003 20:13:59 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:13:58 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 20:13:57 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 20:13:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Geopriv] RE: [Simple] Changes in xcap-auth Message-ID: Thread-Topic: [Geopriv] RE: [Simple] Changes in xcap-auth Thread-Index: AcOlcBUfBxdthOUzTvCAqtdFH0QNiABVwQuA To: , Cc: , , , X-OriginalArrivalTime: 09 Nov 2003 18:13:57.0481 (UTC) FILETIME=[3E0A0590:01C3A6ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 20:13:56 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I've followed this thread from SIMPLE WG point of view. I agree mostly = with what Jonathan is writing below. I summarize my main points here: - In many "domains" (run by corporates, ISPs, operators) it is not = possible to ad hoc create new identities, and in any case authentication = is always required when an identity is used. This means that getting = around "black lists" is not as trivial as in e-mail.=20 - I agree that the usefulness of exceptions depends on how "group" = information is structured. In many cases, especially in corporates, = people use groups/lists that they themselves are not able to manage (and = in some cases not even see their content). This happens with e-mail, = calendars etc. I believe similar shared groups to be useful for = hobby-clubs, families etc. too. In those cases it is important to be = able to disclude some members by doing exceptions, e.g. "golf-club-list = EXCEPT Joe" or "engineering-department-list EXCEPT my boss". I = understood Ted's point that UI and protocol can be separated, but I = share Jonathan's concern below. - I didn't quite get why we couldn't define the and = so that if the part for some reason (external = reference etc.) could not be properly resolved, the whole = would result in empty set, i.e. at least no leaks would be introduced. - Also I did't get what was wrong with Ted's proposal to define a = separate element. To me that would be OK as = well. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 07 November, 2003 22:22 > To: Henning Schulzrinne > Cc: Andrew Newton; Naoko ITO; Simple WG; geopriv@ietf.org > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth >=20 >=20 > inline. >=20 > Henning Schulzrinne wrote: >=20 > >>> I don't understand why the except clause in each permission > >>> statement should be dismissed while the separate exception list > >>> model can be supported. > >=20 > >=20 > > The exception list is restricted in its functionality to avoid the > > privacy problems caused by exception entries. Mixing the two means > > that both list types would need to be restricted as described. > >=20 > > Also, having unbounded except lists makes processing more > > complicated since the simple row model no longer applies (it's no > > longer a relational table). >=20 > I share Ito-san's confusion here. Assuming the same kind of > restrictions you have asked for - no external references, no > wildcards, no domain-scopes, I dont see the difference between: >=20 > > example.com > > joe@example.com > > >=20 > and: >=20 > > example.com > >=20 > > joe@example.com > >=20 > THe differences seem merely syntactic, but maybe I am missing > something here. >=20 > Henning also wrote: > > Blacklists were popular for spam-protection early on, but I think > > everyone has realized by now that they are close to useless. I'd > > hate to create a complicated, brittle, difficult-to-predict system > > just to find out a year later that this expensive feature turned > > out to be mostly an empty promise, in terms of increasing user > > privacy. >=20 > There are some serious differences here with the email spam case.=20 > Firstly, the systems we are talking about require authentication,=20 > which is absent in email. Secondly, and perhaps most=20 > importantly, I am=20 > not interested in rules like "allow anyone in the world but=20 > bob@example.com", as I agree this is silly. We are talking=20 > about rules=20 > like "allow only people from example.com EXCEPT=20 > bob@example.com". That=20 > is, I expect these systems to require a user to explicitly grant a=20 > permission, but an extremely common case, I think, will be to=20 > grant it=20 > by indicating a domain with a set of exceptions. >=20 > Ted wrote: > > To take up your point on implementation, I note that > > folks do seem to be assuming a connection between > > the UI and the protocol behavior. I can easily see > > a UI saying "Grant all buddies civil geolocation data > > at City level, except $ex-spouse, who should get > > my timezone" and translating that as a grant of > > timezone to all buddies and a second grant of > > City to each of those that isn't the ex-spouse. From > > the user point of view, it's an "except", where from the > > protocol point of view it is additive permissions. > >=20 > > There is no question that there are engineering trade-offs here. > > You gain simplicity and have an easy method to > > ensure maximal privacy, but you may get increased > > object size and you may need to structure group data > > in ways that ensure it fits this model reasonably > > efficiently. Neither choice is perfect, but this one > > does have some very useful characteristics for a > > large number of GeoPriv cases. There may be other > > usage patterns in other uses of XCAP that mean > > we can't have a perfect fit, but if we can keep that > > split to a minimum, I think it's worth it. >=20 > To summarize (correct me if I am wrong), I think your suggestion was=20 > that exceptions can be handled by expanding the lists associated with=20 > the domain. As such, even though the user sees an exception rule in=20 > the UI, the underlying system pushes a permission with everyone in it. >=20 > My concern is that I believe this will be very difficult to=20 > manage. It=20 > requires the users to have access to the set of users in the domain=20 > from which the exceptions are being specified. That list is=20 > undoubtedly dynamic, and potentially pretty large. When a new=20 > employee=20 > joins the company, everyone would have to update their=20 > permissiosn (or=20 > have their agents do it automatically somehow), and similarly when=20 > someone leaves. The result will be odd behavior for users, where=20 > people that a user believes to have permission, actually doesnt. >=20 > -Jonathan R. >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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-admin@ietf.org Sun Nov 9 14:04:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05199; Sun, 9 Nov 2003 13:15:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu5g-0004ml-00; Sun, 09 Nov 2003 13:15:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIu5f-0004ma-00; Sun, 09 Nov 2003 13:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu5X-0004sI-L7; Sun, 09 Nov 2003 13:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIu4g-0004rT-6s for simple@optimus.ietf.org; Sun, 09 Nov 2003 13:14:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05173 for ; Sun, 9 Nov 2003 13:13:55 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4e-0004mD-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AIu4d-0004mA-00 for simple@ietf.org; Sun, 09 Nov 2003 13:14:07 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA9IE6e08973 for ; Sun, 9 Nov 2003 20:14:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Nov 2003 20:14:05 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 9 Nov 2003 20:14:04 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 9 Nov 2003 20:14:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Questions on XCAP Usage for Authorization Message-ID: Thread-Topic: [Simple] Questions on XCAP Usage for Authorization Thread-Index: AcOf6b8zMihRfp+vR++EmP1IKG5GlQG42Row To: , Cc: X-OriginalArrivalTime: 09 Nov 2003 18:14:04.0480 (UTC) FILETIME=[4235FC00:01C3A6ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 9 Nov 2003 20:14:04 +0200 Content-Transfer-Encoding: quoted-printable Hi, Jonathan Rosenberg replies to Naoko Ito: > > - Is there any way to reject a watcher who is given permissions by > > other statements? > > ex) Give a permission to any user whose domain is=20 > "example.com" but > > Joe. >=20 > Yes, now that is possible in -01. You would define a statement that=20 > allows anyone but Joe: >=20 > > > example.com > > sip:joe@example.com > > >=20 > > >=20 > and to reject Joe, there would be this statement: >=20 > > > sip:joe@example.com > > >=20 > Note how, in the second statement, there is an applies-to, but *no*=20 > permissions. I.e., the way to reject someone is that they are granted=20 > no permissions. If the default is that no-one is granted no permissions, what is the = difference the second statement makes? Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 31 October, 2003 22:00 > To: Naoko ITO > Cc: simple@ietf.org > Subject: Re: [Simple] Questions on XCAP Usage for Authorization >=20 >=20 > Sorry for the delay in responding. Answers inline. >=20 > Naoko ITO wrote: >=20 > > Hello, > >=20 > > I have some questions on XCAP Usage for Authorization. > >=20 > > The draft says, > > The overall authorization for a watcher is represented=20 > by the union > > of the permissions granted to that watcher. > > and > > In that case, the union of the permissions across those=20 > statements > > is applied to the subscription. > >=20 > > Am I correctly understanding that the overall authorization is > > determined by simply putting together every permission related to a > > specific watcher? >=20 > Yes. >=20 > >=20 > > Then, some questions occur to me. > >=20 > > - Is there any way to reject a watcher who is given permissions by > > other statements? > > ex) Give a permission to any user whose domain is=20 > "example.com" but > > Joe. >=20 > Yes, now that is possible in -01. You would define a statement that=20 > allows anyone but Joe: >=20 > > > example.com > > sip:joe@example.com > > >=20 > > >=20 > and to reject Joe, there would be this statement: >=20 > > > sip:joe@example.com > > >=20 > Note how, in the second statement, there is an applies-to, but *no*=20 > permissions. I.e., the way to reject someone is that they are granted=20 > no permissions. >=20 >=20 > > - Is there a way to have a default policy which can be overridden by > > other statements? It seems possible to reject, or not to give a > > permission to all the watchers by default and add permisions to > > specific users only. But it does not seem possible to accept every > > user by default unless listed on a black list. >=20 > Sure, you can do that. You would have two-statements: >=20 > > > > > http://xcap.example.com/resource-lists/users/joe/ > black-list > > >=20 > > >=20 > > > http://xcap.example.com/resource-lists/users/joe/ > black-list > > >=20 > This is now possible because of the except clause which I=20 > added in -01. >=20 >=20 > > - How to solve the conflicts between two or more=20 > permissions related to > > one watcher? >=20 > Ahh, thats the whole idea. >=20 > There *can't* be conflicts. By defining the permissions as additive=20 > always, you never have conflicts. Geopriv has taken the exact same=20 > approach. >=20 >=20 > >=20 > > I understand this is still under discussion, as it says, > >=20 > > OPEN ISSUE: Another model is that you take permissions for the > > most specific match. I think union makes more sense=20 > in the model > > where the entries in the statement are permissions. > >=20 > > but it'd be greatful if I can be provided any idea on this. >=20 > I think we've concluded here. I believe that the appropriate model is=20 > as specified. With the addition of the except clause, I am confident=20 > that we can easily specify a wide range of things, and furthermore,=20 > have a model which always maximizes privacy. You never have to worry=20 > about information being given out by accident because some blocking=20 > rule was overriden with a permission rule. People only get=20 > information=20 > when they are granted an explicit permission. >=20 > Given that geopriv has also chosen this model, its clear to me that=20 > its the right way to go. >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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-admin@ietf.org Mon Nov 10 01:00:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26809; Mon, 10 Nov 2003 01:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ56q-0007IM-00; Mon, 10 Nov 2003 01:01:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ56p-0007IJ-00; Mon, 10 Nov 2003 01:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ56k-0008Ss-48; Mon, 10 Nov 2003 01:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ56F-0008LH-55 for simple@optimus.ietf.org; Mon, 10 Nov 2003 01:00:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26771; Mon, 10 Nov 2003 01:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ56B-0007Eb-00; Mon, 10 Nov 2003 01:00:27 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJ56A-0007E7-00; Mon, 10 Nov 2003 01:00:27 -0500 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAA5xhca014434; Mon, 10 Nov 2003 00:59:44 -0500 (EST) Message-ID: <3FAF294D.3010308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Markus.Isomaki@nokia.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <3FAE8B6A.7070101@cs.columbia.edu> In-Reply-To: <3FAE8B6A.7070101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 00:59:41 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > >> "group" information is structured. In many cases, especially in >> corporates, people use groups/lists that they themselves are not able >> to manage (and in some cases not even see their content). This >> happens with e-mail, calendars etc. I believe similar shared groups >> to be useful for hobby-clubs, families etc. too. In those cases it is >> important to be able to disclude some members by doing exceptions, >> e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list >> EXCEPT my boss". I understood Ted's point that UI and protocol can be >> separated, but I share Jonathan's concern below. > > > These types of groups are rather different from identities as there is > no way for a user to log in as 'member of bowling team'. Thus, I think > it would be confusing to treat them just like another identifier. > > Whether to allow matching on group membership is another matter, but it > would likely be a separate 'column'. > > The problem with groups is that there is no unique way to check for > group membership in general. There is also no global namespace for them, > so that there is no guarantee that two servers that see a rule set > reference will make the same determination. (We obviously have email > lists and maybe even SIP replication lists and buddy lists, but they are > unresolvable outside a very narrow context.) I agree that groups are a separate issue. However, in xcap, it currently does allow for things like "applies to everyone on golf-list, but Joe". It does that by having each group defined by an xcap resource (i.e., an http URI) that can be used to fetch the group list. Then, membership in the group is determined by authenticating as one of the identities in that group. If you can't fetch the list, the permission isnt granted, and thus its privacy safe. If, for some reason, a user specifies a rule based on a list in another domain, with members in other domains, the server can't authenticate those users, and thus permissions are not granted, and thus its privacy safe. You *would* have problems if you could have an exception defined by an external list, but I agree we shouldnt do that. So, given this design and assumptions, I dont see a problem with groups per se. There is a scope question, but I dont see a technical problem. > > > - I didn't quite get > >> why we couldn't define the and so that if >> the part for some reason (external reference etc.) could >> not be properly resolved, the whole would result in >> empty set, i.e. at least no leaks would be introduced. - Also I did't >> get what was wrong with Ted's proposal to define a separate >> element. To me that would be OK as well. >> > > I don't think we're all that far apart. > > Since assumptions are rather important in this whole discussion, let me > state my current view of what can and cannot be done. > > - Each rule must have the exceptions atomically encoded in the same > rule, i.e., the rule cannot refer to exceptions elsewhere. The > exceptions simply restrict the cases where the rule matches. In other > words, exceptions within rule A do not influence the behavior of rule B. Agreed. > > - Some systems will have multiple rulesets, e.g., one stored at the > server and one carried by the location update. In general, we need to be > sure that it is clear what happens in cases such as > > Rule 1: example.com except alice@example.com > Rule 2: example.com except bob@example.com > > In the additive model, Bob will get the permissions in Rule 1. This may > or may not be what users want. (If people are happy with that, I think > we can make that work.) I think that is fine. It is consistent with the exception semantics I have been arguing for. The main thing is that the semantics are clear. How these things are presented to users is something else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 01:01:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26867 for ; Mon, 10 Nov 2003 01:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ56u-000075-I7 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 01:01:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAA61CFo000434 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 01:01:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ56u-00006v-EZ for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 01:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26809; Mon, 10 Nov 2003 01:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ56q-0007IM-00; Mon, 10 Nov 2003 01:01:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJ56p-0007IJ-00; Mon, 10 Nov 2003 01:01:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ56k-0008Ss-48; Mon, 10 Nov 2003 01:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJ56F-0008LH-55 for simple@optimus.ietf.org; Mon, 10 Nov 2003 01:00:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26771; Mon, 10 Nov 2003 01:00:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJ56B-0007Eb-00; Mon, 10 Nov 2003 01:00:27 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJ56A-0007E7-00; Mon, 10 Nov 2003 01:00:27 -0500 Received: from dynamicsoft.com ([63.113.46.126]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAA5xhca014434; Mon, 10 Nov 2003 00:59:44 -0500 (EST) Message-ID: <3FAF294D.3010308@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Markus.Isomaki@nokia.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <3FAE8B6A.7070101@cs.columbia.edu> In-Reply-To: <3FAE8B6A.7070101@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 00:59:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > >> "group" information is structured. In many cases, especially in >> corporates, people use groups/lists that they themselves are not able >> to manage (and in some cases not even see their content). This >> happens with e-mail, calendars etc. I believe similar shared groups >> to be useful for hobby-clubs, families etc. too. In those cases it is >> important to be able to disclude some members by doing exceptions, >> e.g. "golf-club-list EXCEPT Joe" or "engineering-department-list >> EXCEPT my boss". I understood Ted's point that UI and protocol can be >> separated, but I share Jonathan's concern below. > > > These types of groups are rather different from identities as there is > no way for a user to log in as 'member of bowling team'. Thus, I think > it would be confusing to treat them just like another identifier. > > Whether to allow matching on group membership is another matter, but it > would likely be a separate 'column'. > > The problem with groups is that there is no unique way to check for > group membership in general. There is also no global namespace for them, > so that there is no guarantee that two servers that see a rule set > reference will make the same determination. (We obviously have email > lists and maybe even SIP replication lists and buddy lists, but they are > unresolvable outside a very narrow context.) I agree that groups are a separate issue. However, in xcap, it currently does allow for things like "applies to everyone on golf-list, but Joe". It does that by having each group defined by an xcap resource (i.e., an http URI) that can be used to fetch the group list. Then, membership in the group is determined by authenticating as one of the identities in that group. If you can't fetch the list, the permission isnt granted, and thus its privacy safe. If, for some reason, a user specifies a rule based on a list in another domain, with members in other domains, the server can't authenticate those users, and thus permissions are not granted, and thus its privacy safe. You *would* have problems if you could have an exception defined by an external list, but I agree we shouldnt do that. So, given this design and assumptions, I dont see a problem with groups per se. There is a scope question, but I dont see a technical problem. > > > - I didn't quite get > >> why we couldn't define the and so that if >> the part for some reason (external reference etc.) could >> not be properly resolved, the whole would result in >> empty set, i.e. at least no leaks would be introduced. - Also I did't >> get what was wrong with Ted's proposal to define a separate >> element. To me that would be OK as well. >> > > I don't think we're all that far apart. > > Since assumptions are rather important in this whole discussion, let me > state my current view of what can and cannot be done. > > - Each rule must have the exceptions atomically encoded in the same > rule, i.e., the rule cannot refer to exceptions elsewhere. The > exceptions simply restrict the cases where the rule matches. In other > words, exceptions within rule A do not influence the behavior of rule B. Agreed. > > - Some systems will have multiple rulesets, e.g., one stored at the > server and one carried by the location update. In general, we need to be > sure that it is clear what happens in cases such as > > Rule 1: example.com except alice@example.com > Rule 2: example.com except bob@example.com > > In the additive model, Bob will get the permissions in Rule 1. This may > or may not be what users want. (If people are happy with that, I think > we can make that work.) I think that is fine. It is consistent with the exception semantics I have been arguing for. The main thing is that the semantics are clear. How these things are presented to users is something else. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 08:53:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19393; Mon, 10 Nov 2003 08:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCUa-0004iK-00; Mon, 10 Nov 2003 08:54:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJCUa-0004iE-00; Mon, 10 Nov 2003 08:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUS-0004OR-Uu; Mon, 10 Nov 2003 08:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCTe-0004NG-Mz for simple@optimus.ietf.org; Mon, 10 Nov 2003 08:53:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19350 for ; Mon, 10 Nov 2003 08:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCTd-0004h8-00 for simple@ietf.org; Mon, 10 Nov 2003 08:53:09 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJCTc-0004gr-00 for simple@ietf.org; Mon, 10 Nov 2003 08:53:08 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2003 05:54:19 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAADqaw5021020; Mon, 10 Nov 2003 05:52:36 -0800 (PST) Received: from [130.129.142.157] (sjc-vpn1-121.cisco.com [10.21.96.121]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU61055; Mon, 10 Nov 2003 05:52:35 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: , Ben Campbell Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Nov 2003 21:16:14 -0800 Content-Transfer-Encoding: 7bit The draft does not say much about if the forming a separate TCP connection for each session between two relays. Some people have said this will use less bandwidth than a single connection. I think it will consume much more. The question is if this is trashing the commons or not - I don't know. Given one of the major reasons for not just using Page mode for everything revolves around concession control, I think it needs a little discussion. Not that we are doing this but ... Setting up a new TCP connection for every UDP packet you want to send completely defeats the congestion control properties of TCP. I would prefer if it said you MUST implement both passive and active. I think it is unacceptable that two clients could be fully compliant with the RFC and not be able to send message to each other. I'm fine with them be configured such that they can't. I don't see the need to support switching to TLS after the first message has been received. This just introduces to many weird things to figure out on authorization. Why would you switch? TLS is way underspecified - what do the certs need to say - how does mutual TLS work - can two relays use self signed certs - how would that work. I know I have threatened to send text before - hopefully I will at some point :-) It's not really clear how you switch to a TLS session. I'm very suspicious that the look ahead scheme to switch to TLS is going to be very hard to integrate with existing libraries - I'm fairly confident that STARTLS will work so why not use it? I still think the draft should explicitly discuss more than two relays. There are many needs to relays and saying put a full B2BUA in to meet all these other needs is bogus. I expect this comment to be ignored :-) I like the resolution of new sessions for large messages or separate conversation threads. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 08:54:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19451 for ; Mon, 10 Nov 2003 08:54:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUe-0004Xu-ST for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 08:54:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAADsCAC017440 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 08:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUe-0004WT-6O for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 08:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19393; Mon, 10 Nov 2003 08:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCUa-0004iK-00; Mon, 10 Nov 2003 08:54:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJCUa-0004iE-00; Mon, 10 Nov 2003 08:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUS-0004OR-Uu; Mon, 10 Nov 2003 08:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCTe-0004NG-Mz for simple@optimus.ietf.org; Mon, 10 Nov 2003 08:53:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19350 for ; Mon, 10 Nov 2003 08:52:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCTd-0004h8-00 for simple@ietf.org; Mon, 10 Nov 2003 08:53:09 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJCTc-0004gr-00 for simple@ietf.org; Mon, 10 Nov 2003 08:53:08 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2003 05:54:19 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAADqaw5021020; Mon, 10 Nov 2003 05:52:36 -0800 (PST) Received: from [130.129.142.157] (sjc-vpn1-121.cisco.com [10.21.96.121]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU61055; Mon, 10 Nov 2003 05:52:35 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: , Ben Campbell Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Nov 2003 21:16:14 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The draft does not say much about if the forming a separate TCP connection for each session between two relays. Some people have said this will use less bandwidth than a single connection. I think it will consume much more. The question is if this is trashing the commons or not - I don't know. Given one of the major reasons for not just using Page mode for everything revolves around concession control, I think it needs a little discussion. Not that we are doing this but ... Setting up a new TCP connection for every UDP packet you want to send completely defeats the congestion control properties of TCP. I would prefer if it said you MUST implement both passive and active. I think it is unacceptable that two clients could be fully compliant with the RFC and not be able to send message to each other. I'm fine with them be configured such that they can't. I don't see the need to support switching to TLS after the first message has been received. This just introduces to many weird things to figure out on authorization. Why would you switch? TLS is way underspecified - what do the certs need to say - how does mutual TLS work - can two relays use self signed certs - how would that work. I know I have threatened to send text before - hopefully I will at some point :-) It's not really clear how you switch to a TLS session. I'm very suspicious that the look ahead scheme to switch to TLS is going to be very hard to integrate with existing libraries - I'm fairly confident that STARTLS will work so why not use it? I still think the draft should explicitly discuss more than two relays. There are many needs to relays and saying put a full B2BUA in to meet all these other needs is bogus. I expect this comment to be ignored :-) I like the resolution of new sessions for large messages or separate conversation threads. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 10:28:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24372; Mon, 10 Nov 2003 10:28:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDxf-00060Z-00; Mon, 10 Nov 2003 10:28:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJDxf-00060V-00; Mon, 10 Nov 2003 10:28:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDxR-0001eb-Dh; Mon, 10 Nov 2003 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDxE-0001eD-9L for simple@optimus.ietf.org; Mon, 10 Nov 2003 10:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24357 for ; Mon, 10 Nov 2003 10:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDxB-0005zy-00 for simple@ietf.org; Mon, 10 Nov 2003 10:27:45 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AJDxA-0005zv-00 for simple@ietf.org; Mon, 10 Nov 2003 10:27:45 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hAAFRg319914; Mon, 10 Nov 2003 10:27:42 -0500 To: Jonathan Rosenberg Cc: simple@ietf.org References: <3FA2B13B.6010401@dynamicsoft.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: <3FA2B13B.6010401@dynamicsoft.com> (Jonathan Rosenberg's message of "Fri, 31 Oct 2003 14:00:11 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 10:27:42 -0500 Jonathan Rosenberg writes: > It had also been proposed to simply continue to use the "/" hierarchy all > the way down into the XML document, i.e.: > > http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/ > resource-list[@id="assd99"] > > where the last two components of the path identify XML elements. I didnt > like this, since practically speaking, implementations are likely going to > want to use the filesystem or DB to retrieve a specific document, and then > use some XML processing to retrieve an element or attribute. So, knowing > where the breakpoint is in the URI is helpful, I think. I prefer the path approach, actually, specifically because it hides the implementation detail - that's none of the clients business, and the server side can do the split anyway. In your example, any of 'xcap.server.com', 'resource-lists', or 'users' would be natural path elements to choose as the one that invokes a database lookup based on the remaining path information (which the server makes available anyway as the CGI variable PATH_INFO). Why should the client be able to tell which way I chose? Why should I have to stick to that choice? -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 10:28:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24407 for ; Mon, 10 Nov 2003 10:28:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDxj-0001h5-PE for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 10:28:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAFSJ6x006510 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 10:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDxj-0001gt-H3 for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 10:28:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24372; Mon, 10 Nov 2003 10:28:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDxf-00060Z-00; Mon, 10 Nov 2003 10:28:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJDxf-00060V-00; Mon, 10 Nov 2003 10:28:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDxR-0001eb-Dh; Mon, 10 Nov 2003 10:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJDxE-0001eD-9L for simple@optimus.ietf.org; Mon, 10 Nov 2003 10:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24357 for ; Mon, 10 Nov 2003 10:27:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJDxB-0005zy-00 for simple@ietf.org; Mon, 10 Nov 2003 10:27:45 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AJDxA-0005zv-00 for simple@ietf.org; Mon, 10 Nov 2003 10:27:45 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hAAFRg319914; Mon, 10 Nov 2003 10:27:42 -0500 To: Jonathan Rosenberg Cc: simple@ietf.org References: <3FA2B13B.6010401@dynamicsoft.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: <3FA2B13B.6010401@dynamicsoft.com> (Jonathan Rosenberg's message of "Fri, 31 Oct 2003 14:00:11 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 10:27:42 -0500 Jonathan Rosenberg writes: > It had also been proposed to simply continue to use the "/" hierarchy all > the way down into the XML document, i.e.: > > http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/ > resource-list[@id="assd99"] > > where the last two components of the path identify XML elements. I didnt > like this, since practically speaking, implementations are likely going to > want to use the filesystem or DB to retrieve a specific document, and then > use some XML processing to retrieve an element or attribute. So, knowing > where the breakpoint is in the URI is helpful, I think. I prefer the path approach, actually, specifically because it hides the implementation detail - that's none of the clients business, and the server side can do the split anyway. In your example, any of 'xcap.server.com', 'resource-lists', or 'users' would be natural path elements to choose as the one that invokes a database lookup based on the remaining path information (which the server makes available anyway as the CGI variable PATH_INFO). Why should the client be able to tell which way I chose? Why should I have to stick to that choice? -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 11:02:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26763; Mon, 10 Nov 2003 11:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEUW-0006s2-00; Mon, 10 Nov 2003 11:02:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEUV-0006ry-00; Mon, 10 Nov 2003 11:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUM-0004uB-8q; Mon, 10 Nov 2003 11:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUB-0004qn-0Y for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26732 for ; Mon, 10 Nov 2003 11:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEU8-0006r8-00 for simple@ietf.org; Mon, 10 Nov 2003 11:01:48 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJEU7-0006r5-00 for simple@ietf.org; Mon, 10 Nov 2003 11:01:47 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAG1EIc031085; Mon, 10 Nov 2003 10:01:26 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAFB649.3000505@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 10:01:13 -0600 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > The draft does not say much about if the forming a separate TCP connection > for each session between two relays. I suspect there is a typo in this sentence: Is the "if" spurious, or is something else missing? (Really, I am not trying to pick at typos--I am just not sure of the meaning.) >Some people have said this will use > less bandwidth than a single connection. I think it will consume much more. I was not aware anyone thought using a connection per session would require less bandwidth than shared connections. The arguments against shared sessions were based on protocol complexity and head-of-line blocking issues. > The question is if this is trashing the commons or not - I don't know. > Given one of the major reasons for not just using Page mode for everything > revolves around concession control, I think it needs a little discussion. > Not that we are doing this but ... Setting up a new TCP connection for every > UDP packet you want to send completely defeats the congestion control > properties of TCP. Do you mean more discussion in the document, or in the work group? We have discussed this a lot in the group, and I have not heard a new argument in a while now... > > I would prefer if it said you MUST implement both passive and active. I > think it is unacceptable that two clients could be fully compliant with the > RFC and not be able to send message to each other. I'm fine with them be > configured such that they can't. Agreed. > > I don't see the need to support switching to TLS after the first message has > been received. This just introduces to many weird things to figure out on > authorization. Why would you switch? I personally agree with your position, but the consensus in Vienna seemed to be to allow switching in mid-stream. It is of course possible that I misunderstood this, and will be _very_ happy to change it if that is the case. > > TLS is way underspecified - what do the certs need to say - how does mutual > TLS work - can two relays use self signed certs - how would that work. I > know I have threatened to send text before - hopefully I will at some point > :-) I share your hope in this matter ;-) > > It's not really clear how you switch to a TLS session. I'm very suspicious > that the look ahead scheme to switch to TLS is going to be very hard to > integrate with existing libraries - I'm fairly confident that STARTLS will > work so why not use it? > > I still think the draft should explicitly discuss more than two relays. > There are many needs to relays and saying put a full B2BUA in to meet all > these other needs is bogus. I expect this comment to be ignored :-) > Noted :-) > I like the resolution of new sessions for large messages or separate > conversation threads. > > 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 exim@www1.ietf.org Mon Nov 10 11:02:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26838 for ; Mon, 10 Nov 2003 11:02:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUZ-0004zV-Td for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:02:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAG2F9P019179 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:02:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUZ-0004zG-Ph for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:02:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26763; Mon, 10 Nov 2003 11:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEUW-0006s2-00; Mon, 10 Nov 2003 11:02:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEUV-0006ry-00; Mon, 10 Nov 2003 11:02:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUM-0004uB-8q; Mon, 10 Nov 2003 11:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEUB-0004qn-0Y for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:01:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26732 for ; Mon, 10 Nov 2003 11:01:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEU8-0006r8-00 for simple@ietf.org; Mon, 10 Nov 2003 11:01:48 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJEU7-0006r5-00 for simple@ietf.org; Mon, 10 Nov 2003 11:01:47 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAG1EIc031085; Mon, 10 Nov 2003 10:01:26 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAFB649.3000505@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] MSRP Comments References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 10:01:13 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > The draft does not say much about if the forming a separate TCP connection > for each session between two relays. I suspect there is a typo in this sentence: Is the "if" spurious, or is something else missing? (Really, I am not trying to pick at typos--I am just not sure of the meaning.) >Some people have said this will use > less bandwidth than a single connection. I think it will consume much more. I was not aware anyone thought using a connection per session would require less bandwidth than shared connections. The arguments against shared sessions were based on protocol complexity and head-of-line blocking issues. > The question is if this is trashing the commons or not - I don't know. > Given one of the major reasons for not just using Page mode for everything > revolves around concession control, I think it needs a little discussion. > Not that we are doing this but ... Setting up a new TCP connection for every > UDP packet you want to send completely defeats the congestion control > properties of TCP. Do you mean more discussion in the document, or in the work group? We have discussed this a lot in the group, and I have not heard a new argument in a while now... > > I would prefer if it said you MUST implement both passive and active. I > think it is unacceptable that two clients could be fully compliant with the > RFC and not be able to send message to each other. I'm fine with them be > configured such that they can't. Agreed. > > I don't see the need to support switching to TLS after the first message has > been received. This just introduces to many weird things to figure out on > authorization. Why would you switch? I personally agree with your position, but the consensus in Vienna seemed to be to allow switching in mid-stream. It is of course possible that I misunderstood this, and will be _very_ happy to change it if that is the case. > > TLS is way underspecified - what do the certs need to say - how does mutual > TLS work - can two relays use self signed certs - how would that work. I > know I have threatened to send text before - hopefully I will at some point > :-) I share your hope in this matter ;-) > > It's not really clear how you switch to a TLS session. I'm very suspicious > that the look ahead scheme to switch to TLS is going to be very hard to > integrate with existing libraries - I'm fairly confident that STARTLS will > work so why not use it? > > I still think the draft should explicitly discuss more than two relays. > There are many needs to relays and saying put a full B2BUA in to meet all > these other needs is bogus. I expect this comment to be ignored :-) > Noted :-) > I like the resolution of new sessions for large messages or separate > conversation threads. > > 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-admin@ietf.org Mon Nov 10 11:06:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27073; Mon, 10 Nov 2003 11:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEZF-0006wP-00; Mon, 10 Nov 2003 11:07:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEZF-0006wM-00; Mon, 10 Nov 2003 11:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEZB-00058x-5e; Mon, 10 Nov 2003 11:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEZ8-00058V-BQ for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27061 for ; Mon, 10 Nov 2003 11:06:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEZ5-0006wA-00 for simple@ietf.org; Mon, 10 Nov 2003 11:06:55 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJEZ4-0006vn-00 for simple@ietf.org; Mon, 10 Nov 2003 11:06:54 -0500 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAAG6Oca014737 for ; Mon, 10 Nov 2003 11:06:25 -0500 (EST) Message-ID: <3FAFB77F.2080903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] comments on draft-isomaki-simple-xcap-publish-usage Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:06:23 -0500 Content-Transfer-Encoding: 7bit I have a few comments on: http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usage-00.txt I think this is a good draft, and is the appropriate way to solve this problem. My main comment is that I think we need to be very clear on the difference between this mechanism and SIP PUBLISH. I know we went through a lot of this on the list some time back. In particular, one could presumably use PUBLISH with an infinitely long Expires header field, and achieve a near "hard state" publication. I think the real difference is that this is provisioned data that describes the presentity independent of any particular device, for which we require any possible device, and even web pages and provisioning systems, to manipulate. PUBLISH is really focused on allowing a particular PUA to publish its view of the presentity, separate from other views published by other PUAs. As such, manipulating presence hard state from many different sources using PUBLISH is not easy, as the Etags would need to be shared. There is no obvious mechanism for that. Also, there will be a clear need to do a pure fetch of the hard state presence data, a feature we don't have with PUBLISH. I think the draft should clearly enumerate these problems, and provide guidance on when to use this mechanism, vs. PUBLISH. Regarding the open issue: > Publishing of external content: how to publish external content > (e.g., an icon) referenced from PIDF in case of the XCAP based > publishing? Is the content transported separately from the PIDF > formatted document so that the PIDF includes only a reference to the > separately transported content and the compositor is capable for > linking the information together? This might require that the > compositor is able to change the content of the reference. This is more of a pidf question, I think. The current leaning with PIDF would be to include such icons by reference. The document stored in the xcap server would include such a reference. That reference would presumably be an HTTP URI that can dreference content on the same server. The user would need to have a directory where they are permitted to upload content. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 11:07:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27107 for ; Mon, 10 Nov 2003 11:07:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEZJ-0005DU-8z for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:07:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAG79JN020043 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:07:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEZI-0005D7-UD for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:07:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27073; Mon, 10 Nov 2003 11:06:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEZF-0006wP-00; Mon, 10 Nov 2003 11:07:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEZF-0006wM-00; Mon, 10 Nov 2003 11:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEZB-00058x-5e; Mon, 10 Nov 2003 11:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEZ8-00058V-BQ for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:06:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27061 for ; Mon, 10 Nov 2003 11:06:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEZ5-0006wA-00 for simple@ietf.org; Mon, 10 Nov 2003 11:06:55 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJEZ4-0006vn-00 for simple@ietf.org; Mon, 10 Nov 2003 11:06:54 -0500 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAAG6Oca014737 for ; Mon, 10 Nov 2003 11:06:25 -0500 (EST) Message-ID: <3FAFB77F.2080903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] comments on draft-isomaki-simple-xcap-publish-usage Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:06:23 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a few comments on: http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usage-00.txt I think this is a good draft, and is the appropriate way to solve this problem. My main comment is that I think we need to be very clear on the difference between this mechanism and SIP PUBLISH. I know we went through a lot of this on the list some time back. In particular, one could presumably use PUBLISH with an infinitely long Expires header field, and achieve a near "hard state" publication. I think the real difference is that this is provisioned data that describes the presentity independent of any particular device, for which we require any possible device, and even web pages and provisioning systems, to manipulate. PUBLISH is really focused on allowing a particular PUA to publish its view of the presentity, separate from other views published by other PUAs. As such, manipulating presence hard state from many different sources using PUBLISH is not easy, as the Etags would need to be shared. There is no obvious mechanism for that. Also, there will be a clear need to do a pure fetch of the hard state presence data, a feature we don't have with PUBLISH. I think the draft should clearly enumerate these problems, and provide guidance on when to use this mechanism, vs. PUBLISH. Regarding the open issue: > Publishing of external content: how to publish external content > (e.g., an icon) referenced from PIDF in case of the XCAP based > publishing? Is the content transported separately from the PIDF > formatted document so that the PIDF includes only a reference to the > separately transported content and the compositor is capable for > linking the information together? This might require that the > compositor is able to change the content of the reference. This is more of a pidf question, I think. The current leaning with PIDF would be to include such icons by reference. The document stored in the xcap server would include such a reference. That reference would presumably be an HTTP URI that can dreference content on the same server. The user would need to have a directory where they are permitted to upload content. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 11:33:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28658; Mon, 10 Nov 2003 11:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEzP-0007WF-00; Mon, 10 Nov 2003 11:34:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEzO-0007WC-00; Mon, 10 Nov 2003 11:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEzI-000786-RW; Mon, 10 Nov 2003 11:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyp-0006z5-Bk for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:33:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28567; Mon, 10 Nov 2003 11:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEyo-0007Vl-00; Mon, 10 Nov 2003 11:33:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJEyn-0007Uq-00; Mon, 10 Nov 2003 11:33:29 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 08:36:12 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAGWtxg019169; Mon, 10 Nov 2003 11:32:56 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-66.cisco.com [10.86.240.66]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW10479; Mon, 10 Nov 2003 11:32:54 -0500 (EST) Message-ID: <3FAFBDB6.4090807@cisco.com> 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 CC: Jonathan Rosenberg , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> <3FAC81AE.4010905@dynamicsoft.com> <3FAD1AAE.3040901@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:32:54 -0500 Content-Transfer-Encoding: 7bit I've been trying to ignore this, but I just can't. Paul Henning Schulzrinne wrote: > >> you can have a pure exception permission. Rather, a permission is >> always additive, but merely defines the set of users that get added by >> specifying a base plus a set of users to remove from that base. To be >> concrete, I would agree that the set of users listed in any except >> clauses *MUST* also be present in a non-except clause in the same >> applies-to statement. This guarantees that the overall applies-to >> statement is purely additive. > > This is indeed a useful additional restriction, but the problem is > deeper than that. You also need to make sure that the same domain or > userid does not appear in other rules. Overlapping rules can come about very naturally via wildcarding: *.ny.example.com sip:alice@sales.ny.example.com sales.*.example.com You can try to legislate that each ruleset covers a unique subset of all users, but that may be restrictive. Jonathan Rosenberg wrote: > > However, in xcap, it currently does allow for things like "applies to > everyone on golf-list, but Joe". It does that by having each group > defined by an xcap resource (i.e., an http URI) that can be used to > fetch the group list. Then, membership in the group is determined by > authenticating as one of the identities in that group. > > If you can't fetch the list, the permission isnt granted, and thus its > privacy safe. This really provides the poster child for the problem of overlapping lists: sip:golf-list@example.com sip:alice@example.com sip:vp-list@example.com What happens if alice is on both the golf-list and the vp-list? Does it matter what order the two clauses are mentioned? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 11:34:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28701 for ; Mon, 10 Nov 2003 11:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEzR-0007A9-C8 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:34:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGY95w027523 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEzR-00079q-1X for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28658; Mon, 10 Nov 2003 11:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEzP-0007WF-00; Mon, 10 Nov 2003 11:34:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEzO-0007WC-00; Mon, 10 Nov 2003 11:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEzI-000786-RW; Mon, 10 Nov 2003 11:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEyp-0006z5-Bk for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:33:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28567; Mon, 10 Nov 2003 11:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEyo-0007Vl-00; Mon, 10 Nov 2003 11:33:30 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJEyn-0007Uq-00; Mon, 10 Nov 2003 11:33:29 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 08:36:12 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAGWtxg019169; Mon, 10 Nov 2003 11:32:56 -0500 (EST) Received: from cisco.com (che-vpn-cluster-1-66.cisco.com [10.86.240.66]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW10479; Mon, 10 Nov 2003 11:32:54 -0500 (EST) Message-ID: <3FAFBDB6.4090807@cisco.com> 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 CC: Jonathan Rosenberg , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> <3FAC81AE.4010905@dynamicsoft.com> <3FAD1AAE.3040901@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:32:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've been trying to ignore this, but I just can't. Paul Henning Schulzrinne wrote: > >> you can have a pure exception permission. Rather, a permission is >> always additive, but merely defines the set of users that get added by >> specifying a base plus a set of users to remove from that base. To be >> concrete, I would agree that the set of users listed in any except >> clauses *MUST* also be present in a non-except clause in the same >> applies-to statement. This guarantees that the overall applies-to >> statement is purely additive. > > This is indeed a useful additional restriction, but the problem is > deeper than that. You also need to make sure that the same domain or > userid does not appear in other rules. Overlapping rules can come about very naturally via wildcarding: *.ny.example.com sip:alice@sales.ny.example.com sales.*.example.com You can try to legislate that each ruleset covers a unique subset of all users, but that may be restrictive. Jonathan Rosenberg wrote: > > However, in xcap, it currently does allow for things like "applies to > everyone on golf-list, but Joe". It does that by having each group > defined by an xcap resource (i.e., an http URI) that can be used to > fetch the group list. Then, membership in the group is determined by > authenticating as one of the identities in that group. > > If you can't fetch the list, the permission isnt granted, and thus its > privacy safe. This really provides the poster child for the problem of overlapping lists: sip:golf-list@example.com sip:alice@example.com sip:vp-list@example.com What happens if alice is on both the golf-list and the vp-list? Does it matter what order the two clauses are mentioned? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 11:47:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29352; Mon, 10 Nov 2003 11:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFCx-0007n3-00; Mon, 10 Nov 2003 11:48:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFCx-0007n0-00; Mon, 10 Nov 2003 11:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFCr-00006f-Vz; Mon, 10 Nov 2003 11:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFCo-00006B-Ul for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29331; Mon, 10 Nov 2003 11:47:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFCn-0007mP-00; Mon, 10 Nov 2003 11:47:57 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJFCm-0007lB-00; Mon, 10 Nov 2003 11:47:56 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAAGk5hL018891; Mon, 10 Nov 2003 11:46:06 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAAGk0f16620; Mon, 10 Nov 2003 11:46:00 -0500 Message-ID: <3FAFC0CE.6060703@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> <3FAC81AE.4010905@dynamicsoft.com> <3FAD1AAE.3040901@cs.columbia.edu> <3FAFBDB6.4090807@cisco.com> In-Reply-To: <3FAFBDB6.4090807@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:46:06 -0500 Content-Transfer-Encoding: 7bit We'll be ok as long as permissions are strictly additive across rules, i.e., if somebody matches two rules (groups, etc.), they'll get the union of the permissions. The geopriv-auth draft provides the arithmetic to do this. I would hope that we can avoid matching on things like foo.*.example.com. That basically makes a database implementation impossible. (While most databases support 'like' and regexp, these only apply to the value being queried; the field value cannot be the pattern.) Paul Kyzivat wrote: > I've been trying to ignore this, but I just can't. > > Paul > > Henning Schulzrinne wrote: > > > >>> you can have a pure exception permission. Rather, a permission is >>> always additive, but merely defines the set of users that get added >>> by specifying a base plus a set of users to remove from that base. To >>> be concrete, I would agree that the set of users listed in any except >>> clauses *MUST* also be present in a non-except clause in the same >>> applies-to statement. This guarantees that the overall applies-to >>> statement is purely additive. >> >> >> This is indeed a useful additional restriction, but the problem is >> deeper than that. You also need to make sure that the same domain or >> userid does not appear in other rules. > > > Overlapping rules can come about very naturally via wildcarding: > > > *.ny.example.com > > sip:alice@sales.ny.example.com > > > > > sales.*.example.com > > > You can try to legislate that each ruleset covers a unique subset of all > users, but that may be restrictive. > > Jonathan Rosenberg wrote: > > > > However, in xcap, it currently does allow for things like "applies to > > everyone on golf-list, but Joe". It does that by having each group > > defined by an xcap resource (i.e., an http URI) that can be used to > > fetch the group list. Then, membership in the group is determined by > > authenticating as one of the identities in that group. > > > > If you can't fetch the list, the permission isnt granted, and thus its > > privacy safe. > > This really provides the poster child for the problem of overlapping lists: > > > sip:golf-list@example.com > > sip:alice@example.com > > > > > sip:vp-list@example.com > > > What happens if alice is on both the golf-list and the vp-list? Does it > matter what order the two clauses are mentioned? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 11:48:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29403 for ; Mon, 10 Nov 2003 11:48:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFD0-0000A4-Bf for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGmAdf000620 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 11:48:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFD0-00009v-8Y for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 11:48:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29352; Mon, 10 Nov 2003 11:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFCx-0007n3-00; Mon, 10 Nov 2003 11:48:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFCx-0007n0-00; Mon, 10 Nov 2003 11:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFCr-00006f-Vz; Mon, 10 Nov 2003 11:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFCo-00006B-Ul for simple@optimus.ietf.org; Mon, 10 Nov 2003 11:47:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29331; Mon, 10 Nov 2003 11:47:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFCn-0007mP-00; Mon, 10 Nov 2003 11:47:57 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJFCm-0007lB-00; Mon, 10 Nov 2003 11:47:56 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAAGk5hL018891; Mon, 10 Nov 2003 11:46:06 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAAGk0f16620; Mon, 10 Nov 2003 11:46:00 -0500 Message-ID: <3FAFC0CE.6060703@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Simple WG , "'geopriv@ietf.org'" Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <2A8DB02E3018D411901B009027FD3A3F03BC03FA@mchp905a.mch.sbs.de> <3FAA9BD7.9070709@dynamicsoft.com> <3FAAF539.2090803@cs.columbia.edu> <3FAC09DC.496B33B4@alcatel.com> <3FAC0E39.7040207@cs.columbia.edu> <3FAC81AE.4010905@dynamicsoft.com> <3FAD1AAE.3040901@cs.columbia.edu> <3FAFBDB6.4090807@cisco.com> In-Reply-To: <3FAFBDB6.4090807@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:46:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We'll be ok as long as permissions are strictly additive across rules, i.e., if somebody matches two rules (groups, etc.), they'll get the union of the permissions. The geopriv-auth draft provides the arithmetic to do this. I would hope that we can avoid matching on things like foo.*.example.com. That basically makes a database implementation impossible. (While most databases support 'like' and regexp, these only apply to the value being queried; the field value cannot be the pattern.) Paul Kyzivat wrote: > I've been trying to ignore this, but I just can't. > > Paul > > Henning Schulzrinne wrote: > > > >>> you can have a pure exception permission. Rather, a permission is >>> always additive, but merely defines the set of users that get added >>> by specifying a base plus a set of users to remove from that base. To >>> be concrete, I would agree that the set of users listed in any except >>> clauses *MUST* also be present in a non-except clause in the same >>> applies-to statement. This guarantees that the overall applies-to >>> statement is purely additive. >> >> >> This is indeed a useful additional restriction, but the problem is >> deeper than that. You also need to make sure that the same domain or >> userid does not appear in other rules. > > > Overlapping rules can come about very naturally via wildcarding: > > > *.ny.example.com > > sip:alice@sales.ny.example.com > > > > > sales.*.example.com > > > You can try to legislate that each ruleset covers a unique subset of all > users, but that may be restrictive. > > Jonathan Rosenberg wrote: > > > > However, in xcap, it currently does allow for things like "applies to > > everyone on golf-list, but Joe". It does that by having each group > > defined by an xcap resource (i.e., an http URI) that can be used to > > fetch the group list. Then, membership in the group is determined by > > authenticating as one of the identities in that group. > > > > If you can't fetch the list, the permission isnt granted, and thus its > > privacy safe. > > This really provides the poster child for the problem of overlapping lists: > > > sip:golf-list@example.com > > sip:alice@example.com > > > > > sip:vp-list@example.com > > > What happens if alice is on both the golf-list and the vp-list? Does it > matter what order the two clauses are mentioned? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 12:06:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00572; Mon, 10 Nov 2003 12:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFVI-0000Oy-00; Mon, 10 Nov 2003 12:07:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFVI-0000Ov-00; Mon, 10 Nov 2003 12:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFVF-0002DK-Bx; Mon, 10 Nov 2003 12:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFUa-00023i-Bi for simple@optimus.ietf.org; Mon, 10 Nov 2003 12:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00526 for ; Mon, 10 Nov 2003 12:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFUZ-0000OA-00 for simple@ietf.org; Mon, 10 Nov 2003 12:06:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJFUY-0000O5-00 for simple@ietf.org; Mon, 10 Nov 2003 12:06:18 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAH6Gc01617 for ; Mon, 10 Nov 2003 19:06:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Nov 2003 19:06:16 +0200 Received: from nokia.com ([10.162.13.26]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 19:06:15 +0200 Message-ID: <3FAFC585.4050107@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2003 17:06:15.0871 (UTC) FILETIME=[F38B44F0:01C3A7AC] Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 19:06:13 +0200 Content-Transfer-Encoding: 7bit Hi, Overall, I like XCAP - it's elegant and well written. My comments are nothing major, but mostly nits and such. Cheers, Aki --- - Chapter 4, paragraph beginning with "Resource Interdependencies", last sentence says: Concretely, this means that, after the server modifies the data, the entity tags are updated as if the client had made the change itself. Does this mean that if the server changes something as a result of the XCAP operation, the change will show as one made by the client? Is that the right way to do it, because in effect this would not require the client to fetch this data, as it would seem like something already up-to-date? I think the proper thing to do would be to make the etag different from the one given to the client. - Chapter 5, 1st paragraph, last sentence seems to be missing text in the beginning which is a little confusing. - Ch. 5.1, 4th paragraph, 1st sentence "identifies a documents". ^^ - Ch 5.2 begins with "The second component". Isn't it rather the third component after the services root URI and AUID+users/global subtree? - Ch 5.2, grammar: The document should give references to the XML specifications. Currently only XPath and XML Schema seem to be there. - Ch 5.2, 3rd paragraph (not counting grammar), s/To determne/To determine/ - Ch 6.5, last paragraph, 2nd s., "...is up the local file..." ^ to - Ch 7.2, 4th paragraph, 4th s., "...matches an ent within..." I guess should be "an existing attribute"? - Ch 7.5, There was already a comment about etags usage on the list, so just to resonate that, it isn't immediately clear what the benefits are for having each attribute in an element have an etag that is independent of that element's etag. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 12:07:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00594 for ; Mon, 10 Nov 2003 12:07:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFVL-0002GO-Ly for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 12:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAH77st008697 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 12:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFVL-0002GC-6j for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:07:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00572; Mon, 10 Nov 2003 12:06:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFVI-0000Oy-00; Mon, 10 Nov 2003 12:07:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFVI-0000Ov-00; Mon, 10 Nov 2003 12:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFVF-0002DK-Bx; Mon, 10 Nov 2003 12:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFUa-00023i-Bi for simple@optimus.ietf.org; Mon, 10 Nov 2003 12:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00526 for ; Mon, 10 Nov 2003 12:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFUZ-0000OA-00 for simple@ietf.org; Mon, 10 Nov 2003 12:06:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJFUY-0000O5-00 for simple@ietf.org; Mon, 10 Nov 2003 12:06:18 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAH6Gc01617 for ; Mon, 10 Nov 2003 19:06:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Nov 2003 19:06:16 +0200 Received: from nokia.com ([10.162.13.26]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 19:06:15 +0200 Message-ID: <3FAFC585.4050107@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2003 17:06:15.0871 (UTC) FILETIME=[F38B44F0:01C3A7AC] Content-Transfer-Encoding: 7bit Subject: [Simple] XCAP comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 19:06:13 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Overall, I like XCAP - it's elegant and well written. My comments are nothing major, but mostly nits and such. Cheers, Aki --- - Chapter 4, paragraph beginning with "Resource Interdependencies", last sentence says: Concretely, this means that, after the server modifies the data, the entity tags are updated as if the client had made the change itself. Does this mean that if the server changes something as a result of the XCAP operation, the change will show as one made by the client? Is that the right way to do it, because in effect this would not require the client to fetch this data, as it would seem like something already up-to-date? I think the proper thing to do would be to make the etag different from the one given to the client. - Chapter 5, 1st paragraph, last sentence seems to be missing text in the beginning which is a little confusing. - Ch. 5.1, 4th paragraph, 1st sentence "identifies a documents". ^^ - Ch 5.2 begins with "The second component". Isn't it rather the third component after the services root URI and AUID+users/global subtree? - Ch 5.2, grammar: The document should give references to the XML specifications. Currently only XPath and XML Schema seem to be there. - Ch 5.2, 3rd paragraph (not counting grammar), s/To determne/To determine/ - Ch 6.5, last paragraph, 2nd s., "...is up the local file..." ^ to - Ch 7.2, 4th paragraph, 4th s., "...matches an ent within..." I guess should be "an existing attribute"? - Ch 7.5, There was already a comment about etags usage on the list, so just to resonate that, it isn't immediately clear what the benefits are for having each attribute in an element have an etag that is independent of that element's etag. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 12:11:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00887; Mon, 10 Nov 2003 12:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFa9-0000UA-00; Mon, 10 Nov 2003 12:12:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFa8-0000U7-00; Mon, 10 Nov 2003 12:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFa4-0002vG-SD; Mon, 10 Nov 2003 12:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFZE-0002gv-NW for simple@optimus.ietf.org; Mon, 10 Nov 2003 12:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00762 for ; Mon, 10 Nov 2003 12:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFZC-0000Rp-00 for simple@ietf.org; Mon, 10 Nov 2003 12:11:06 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJFZB-0000RZ-00 for simple@ietf.org; Mon, 10 Nov 2003 12:11:06 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAH8rIc037554; Mon, 10 Nov 2003 11:08:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAFC623.6000700@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> In-Reply-To: <3FAC2661.70106@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:08:51 -0600 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > > I'm not certain a time period is really necessary. I think this can be > local option. > > Even uniqueness across streams isn't *required*, though it would be > helpful. Instead, we can simply introduce an error response to be used > when a duplicate is detected and supressed. If it was supressed in error > because the sender duplicated a TR-ID from another stream, the sender > would then know to recover. > > But I agree that some further clarification on TR-ID uniqueness could be > helpful. > If TR-ID is not required to be unique across sessions, and you allow clients to attempt to find duplicate messages using TR-ID across sessions, then you introduce the possibility of false detection caused by TR-ID collisions. This seems bad to me. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 12:12:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00989 for ; Mon, 10 Nov 2003 12:12:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFaB-000301-Ta for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 12:12:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAHC7QW011523 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 12:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFaB-0002zm-N5 for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 12:12:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00887; Mon, 10 Nov 2003 12:11:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFa9-0000UA-00; Mon, 10 Nov 2003 12:12:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJFa8-0000U7-00; Mon, 10 Nov 2003 12:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFa4-0002vG-SD; Mon, 10 Nov 2003 12:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFZE-0002gv-NW for simple@optimus.ietf.org; Mon, 10 Nov 2003 12:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00762 for ; Mon, 10 Nov 2003 12:10:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFZC-0000Rp-00 for simple@ietf.org; Mon, 10 Nov 2003 12:11:06 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJFZB-0000RZ-00 for simple@ietf.org; Mon, 10 Nov 2003 12:11:06 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAH8rIc037554; Mon, 10 Nov 2003 11:08:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAFC623.6000700@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> In-Reply-To: <3FAC2661.70106@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 11:08:51 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: [...] > > I'm not certain a time period is really necessary. I think this can be > local option. > > Even uniqueness across streams isn't *required*, though it would be > helpful. Instead, we can simply introduce an error response to be used > when a duplicate is detected and supressed. If it was supressed in error > because the sender duplicated a TR-ID from another stream, the sender > would then know to recover. > > But I agree that some further clarification on TR-ID uniqueness could be > helpful. > If TR-ID is not required to be unique across sessions, and you allow clients to attempt to find duplicate messages using TR-ID across sessions, then you introduce the possibility of false detection caused by TR-ID collisions. This seems bad to me. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 14:33:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07721; Mon, 10 Nov 2003 14:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHnZ-0002yQ-00; Mon, 10 Nov 2003 14:34:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJHnY-0002yL-00; Mon, 10 Nov 2003 14:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHnU-00036a-WB; Mon, 10 Nov 2003 14:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHn1-00031F-0E for simple@optimus.ietf.org; Mon, 10 Nov 2003 14:33:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07633 for ; Mon, 10 Nov 2003 14:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHmy-0002xU-00 for simple@ietf.org; Mon, 10 Nov 2003 14:33:28 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJHmx-0002vs-00 for simple@ietf.org; Mon, 10 Nov 2003 14:33:27 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAAJWhGd011266 for ; Mon, 10 Nov 2003 13:32:44 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 13:32:42 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Simple WG Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 13:32:32 -0600 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > (3) its a CID URI, referring to the list in the body of the request That has the potential to make routing very difficult. If the first proxy that you hit doesn't know what the cid scheme means, then things won't work. It seems to me that the most flexible approach would be something like: SUBSCRIBE sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 Nice thing about this is that you could also do something like: SUBSCRIBE sip:group@example.com;list=http://xcap.example.com/services/presence-lists/u sers/bill/fr.xml SIP/2.0 /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 14:34:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07762 for ; Mon, 10 Nov 2003 14:34:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHnd-00038Y-Bi for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 14:34:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJY9Ip012052 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 14:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHnd-00038J-4r for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:34:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07721; Mon, 10 Nov 2003 14:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHnZ-0002yQ-00; Mon, 10 Nov 2003 14:34:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJHnY-0002yL-00; Mon, 10 Nov 2003 14:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHnU-00036a-WB; Mon, 10 Nov 2003 14:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHn1-00031F-0E for simple@optimus.ietf.org; Mon, 10 Nov 2003 14:33:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07633 for ; Mon, 10 Nov 2003 14:33:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHmy-0002xU-00 for simple@ietf.org; Mon, 10 Nov 2003 14:33:28 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJHmx-0002vs-00 for simple@ietf.org; Mon, 10 Nov 2003 14:33:27 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAAJWhGd011266 for ; Mon, 10 Nov 2003 13:32:44 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 13:32:42 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Jonathan Rosenberg , Simple WG Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 13:32:32 -0600 Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > (3) its a CID URI, referring to the list in the body of the request That has the potential to make routing very difficult. If the first proxy that you hit doesn't know what the cid scheme means, then things won't work. It seems to me that the most flexible approach would be something like: SUBSCRIBE sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 Nice thing about this is that you could also do something like: SUBSCRIBE sip:group@example.com;list=http://xcap.example.com/services/presence-lists/u sers/bill/fr.xml SIP/2.0 /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 14:49:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08648; Mon, 10 Nov 2003 14:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI2z-0003Gx-00; Mon, 10 Nov 2003 14:50:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJI2z-0003Gu-00; Mon, 10 Nov 2003 14:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI2z-0004iL-68; Mon, 10 Nov 2003 14:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI24-0004bA-Gm for simple@optimus.ietf.org; Mon, 10 Nov 2003 14:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08567 for ; Mon, 10 Nov 2003 14:48:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI21-0003G4-00 for simple@ietf.org; Mon, 10 Nov 2003 14:49:01 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJI21-0003Fh-00 for simple@ietf.org; Mon, 10 Nov 2003 14:49:01 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAAJkGGd011303; Mon, 10 Nov 2003 13:46:16 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 13:46:16 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865E0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" Cc: "'simple@ietf.org'" Subject: RE: [Simple] MSRP Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 13:46:07 -0600 Cullen Jennings writes: > I'm very suspicious that the look ahead scheme to switch to > TLS is going to be very hard to integrate with existing > libraries Like OpenSSL? int Msrp::read(char *buffer, int maxLen) { int len; int magic; if (!usingSsl) { len = recv(s, &magic, 4, MSG_PEEK); if ((htonl(magic) >> 8) == 0x160301) { SSL_set_fd(ssl, s); usingSsl = true; } else { len = read(s, buffer, maxLen); } } if (usingSsl) { len = SSL_read(ssl, buffer, maxLen); } return len; } (modulo error checking) /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 14:50:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08687 for ; Mon, 10 Nov 2003 14:50:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI33-0004lJ-JG for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 14:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJo5Sq018299 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 14:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI33-0004l4-EZ for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08648; Mon, 10 Nov 2003 14:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI2z-0003Gx-00; Mon, 10 Nov 2003 14:50:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJI2z-0003Gu-00; Mon, 10 Nov 2003 14:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI2z-0004iL-68; Mon, 10 Nov 2003 14:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI24-0004bA-Gm for simple@optimus.ietf.org; Mon, 10 Nov 2003 14:49:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08567 for ; Mon, 10 Nov 2003 14:48:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI21-0003G4-00 for simple@ietf.org; Mon, 10 Nov 2003 14:49:01 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJI21-0003Fh-00 for simple@ietf.org; Mon, 10 Nov 2003 14:49:01 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAAJkGGd011303; Mon, 10 Nov 2003 13:46:16 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 13:46:16 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865E0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" Cc: "'simple@ietf.org'" Subject: RE: [Simple] MSRP Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 13:46:07 -0600 Cullen Jennings writes: > I'm very suspicious that the look ahead scheme to switch to > TLS is going to be very hard to integrate with existing > libraries Like OpenSSL? int Msrp::read(char *buffer, int maxLen) { int len; int magic; if (!usingSsl) { len = recv(s, &magic, 4, MSG_PEEK); if ((htonl(magic) >> 8) == 0x160301) { SSL_set_fd(ssl, s); usingSsl = true; } else { len = read(s, buffer, maxLen); } } if (usingSsl) { len = SSL_read(ssl, buffer, maxLen); } return len; } (modulo error checking) /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 14:51:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08756; Mon, 10 Nov 2003 14:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI4z-0003Ix-00; Mon, 10 Nov 2003 14:52:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJI4z-0003Ir-00; Mon, 10 Nov 2003 14:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI4v-0004qM-6v; Mon, 10 Nov 2003 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI4o-0004pO-NZ for simple@optimus.ietf.org; Mon, 10 Nov 2003 14:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08733; Mon, 10 Nov 2003 14:51:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI4l-0003IE-00; Mon, 10 Nov 2003 14:51:51 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJI4k-0003I4-00; Mon, 10 Nov 2003 14:51:51 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAAJkehL012587; Mon, 10 Nov 2003 14:46:41 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAAJk4f18906; Mon, 10 Nov 2003 14:46:04 -0500 Message-ID: <3FAFEAFF.10601@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Markus.Isomaki@nokia.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <3FAE8B6A.7070101@cs.columbia.edu> <3FAF294D.3010308@dynamicsoft.com> In-Reply-To: <3FAF294D.3010308@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:46:07 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I agree that groups are a separate issue. > > However, in xcap, it currently does allow for things like "applies to > everyone on golf-list, but Joe". It does that by having each group > defined by an xcap resource (i.e., an http URI) that can be used to > fetch the group list. Then, membership in the group is determined by > authenticating as one of the identities in that group. > > If you can't fetch the list, the permission isnt granted, and thus its > privacy safe. Clearly, fetching group lists adds significant complexity: expiration (presumably you don't want to fetch it every time) and the inability, without significant overhead, to implement a permission system using any reasonably efficient query mechanism. > > If, for some reason, a user specifies a rule based on a list in another > domain, with members in other domains, the server can't authenticate > those users, and thus permissions are not granted, and thus its privacy > safe. > > You *would* have problems if you could have an exception defined by an > external list, but I agree we shouldnt do that. > > So, given this design and assumptions, I dont see a problem with groups > per se. There is a scope question, but I dont see a technical problem. It just makes efficient implementation difficult to impossible. > > The main thing is that the semantics are clear. How these things are > presented to users is something else. If nothing else, the discussion has hopefully clarified the semantics a bit beyond what's in the drafts and meeting minutes. I guess at this point, if anybody wants exceptions beyond that, they should speak up. I would also like to get consensus to rule out random wildcard matching and, less importantly, domain exceptions. Thus, applies-to: foo.*.example.com and applies-to: example.com except cs.example.com seem far less useful and add significant complexity. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 14:52:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08803 for ; Mon, 10 Nov 2003 14:52:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI53-0004xQ-EG for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 14:52:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJq9d6019050 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 14:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI53-0004xB-9v for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 14:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08756; Mon, 10 Nov 2003 14:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI4z-0003Ix-00; Mon, 10 Nov 2003 14:52:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJI4z-0003Ir-00; Mon, 10 Nov 2003 14:52:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI4v-0004qM-6v; Mon, 10 Nov 2003 14:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJI4o-0004pO-NZ for simple@optimus.ietf.org; Mon, 10 Nov 2003 14:51:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08733; Mon, 10 Nov 2003 14:51:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJI4l-0003IE-00; Mon, 10 Nov 2003 14:51:51 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AJI4k-0003I4-00; Mon, 10 Nov 2003 14:51:51 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAAJkehL012587; Mon, 10 Nov 2003 14:46:41 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAAJk4f18906; Mon, 10 Nov 2003 14:46:04 -0500 Message-ID: <3FAFEAFF.10601@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Markus.Isomaki@nokia.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <3FAE8B6A.7070101@cs.columbia.edu> <3FAF294D.3010308@dynamicsoft.com> In-Reply-To: <3FAF294D.3010308@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:46:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > I agree that groups are a separate issue. > > However, in xcap, it currently does allow for things like "applies to > everyone on golf-list, but Joe". It does that by having each group > defined by an xcap resource (i.e., an http URI) that can be used to > fetch the group list. Then, membership in the group is determined by > authenticating as one of the identities in that group. > > If you can't fetch the list, the permission isnt granted, and thus its > privacy safe. Clearly, fetching group lists adds significant complexity: expiration (presumably you don't want to fetch it every time) and the inability, without significant overhead, to implement a permission system using any reasonably efficient query mechanism. > > If, for some reason, a user specifies a rule based on a list in another > domain, with members in other domains, the server can't authenticate > those users, and thus permissions are not granted, and thus its privacy > safe. > > You *would* have problems if you could have an exception defined by an > external list, but I agree we shouldnt do that. > > So, given this design and assumptions, I dont see a problem with groups > per se. There is a scope question, but I dont see a technical problem. It just makes efficient implementation difficult to impossible. > > The main thing is that the semantics are clear. How these things are > presented to users is something else. If nothing else, the discussion has hopefully clarified the semantics a bit beyond what's in the drafts and meeting minutes. I guess at this point, if anybody wants exceptions beyond that, they should speak up. I would also like to get consensus to rule out random wildcard matching and, less importantly, domain exceptions. Thus, applies-to: foo.*.example.com and applies-to: example.com except cs.example.com seem far less useful and add significant complexity. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 15:09:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10064; Mon, 10 Nov 2003 15:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIMR-0003fd-00; Mon, 10 Nov 2003 15:10:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIMR-0003fa-00; Mon, 10 Nov 2003 15:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIML-0006WS-NM; Mon, 10 Nov 2003 15:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJILd-0006Vq-OS for simple@optimus.ietf.org; Mon, 10 Nov 2003 15:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09962 for ; Mon, 10 Nov 2003 15:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJILX-0003eN-00 for simple@ietf.org; Mon, 10 Nov 2003 15:09:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJILW-0003e0-00 for simple@ietf.org; Mon, 10 Nov 2003 15:09:10 -0500 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAAK8fca014885; Mon, 10 Nov 2003 15:08:41 -0500 (EST) Message-ID: <3FAFF046.4020409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:08:38 -0500 Content-Transfer-Encoding: 7bit I think what you are proposing is a hybrid between approach (3) and my approach (1): > (1) its a well-known service URI, for example, > sip:adhoclist@domain.com, where the server knows that for any > subscriptions to sip:adhoclist@, it means that the > subscription has its contents in the body That is, we are using a well known service URI, but the list to use for that subscription is obtained by dereferencing a parameter in the URI (or possibly in a header field). -Jonathan R. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > >> (3) its a CID URI, referring to the list in the body of the >> request > > That has the potential to make routing very difficult. If the first > proxy that you hit doesn't know what the cid scheme means, then > things won't work. It seems to me that the most flexible approach > would be something like: > > SUBSCRIBE > sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > Nice thing about this is that you could also do something like: > > SUBSCRIBE > sip:group@example.com;list=http://xcap.example.com/services/presence-lists/users/bill/fr.xml > SIP/2.0 > > /a > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 15:10:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10107 for ; Mon, 10 Nov 2003 15:10:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIMV-0006ai-NE for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 15:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKABiQ025330 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 15:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIMV-0006YU-J0 for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10064; Mon, 10 Nov 2003 15:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIMR-0003fd-00; Mon, 10 Nov 2003 15:10:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIMR-0003fa-00; Mon, 10 Nov 2003 15:10:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIML-0006WS-NM; Mon, 10 Nov 2003 15:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJILd-0006Vq-OS for simple@optimus.ietf.org; Mon, 10 Nov 2003 15:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09962 for ; Mon, 10 Nov 2003 15:09:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJILX-0003eN-00 for simple@ietf.org; Mon, 10 Nov 2003 15:09:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJILW-0003e0-00 for simple@ietf.org; Mon, 10 Nov 2003 15:09:10 -0500 Received: from dynamicsoft.com ([63.113.46.8]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAAK8fca014885; Mon, 10 Nov 2003 15:08:41 -0500 (EST) Message-ID: <3FAFF046.4020409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:08:38 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think what you are proposing is a hybrid between approach (3) and my approach (1): > (1) its a well-known service URI, for example, > sip:adhoclist@domain.com, where the server knows that for any > subscriptions to sip:adhoclist@, it means that the > subscription has its contents in the body That is, we are using a well known service URI, but the list to use for that subscription is obtained by dereferencing a parameter in the URI (or possibly in a header field). -Jonathan R. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > >> (3) its a CID URI, referring to the list in the body of the >> request > > That has the potential to make routing very difficult. If the first > proxy that you hit doesn't know what the cid scheme means, then > things won't work. It seems to me that the most flexible approach > would be something like: > > SUBSCRIBE > sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > Nice thing about this is that you could also do something like: > > SUBSCRIBE > sip:group@example.com;list=http://xcap.example.com/services/presence-lists/users/bill/fr.xml > SIP/2.0 > > /a > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 15:29:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11744; Mon, 10 Nov 2003 15:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIfm-00044n-00; Mon, 10 Nov 2003 15:30:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIfm-00044k-00; Mon, 10 Nov 2003 15:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIfi-00082h-HR; Mon, 10 Nov 2003 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIfN-00081y-JA for simple@optimus.ietf.org; Mon, 10 Nov 2003 15:29:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11722; Mon, 10 Nov 2003 15:29:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIfL-000444-00; Mon, 10 Nov 2003 15:29:39 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJIfK-00043O-00; Mon, 10 Nov 2003 15:29:39 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAAKT1Gd011429; Mon, 10 Nov 2003 14:29:02 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 14:29:01 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Andrew Newton'" , Naoko ITO Cc: Simple WG , geopriv@ietf.org Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:28:59 -0600 The difficult issue here is knowledge of group membership. As has been proposed earlier, the correct way to say "everyone in my buddy list *except* Bob" is to literally have your client send the list of everyone in your buddy list except Bob. For this specific example, I can agree with the approach of "just explicitly grant permissions." Now, if a user wants to semantically say "everyone in engineering at my company except Bob," it gets much more difficult. From a user perspective in this case, what he needs to say is "everyone in engineering except Bob." He doesn't care about the underlying protocol -- that's the behavior he wants, and anything else is broken. To make this model work without an "except" clause, my client would need to have a mechanism to fetch all the engineering users from the corporate directory, remove Bob from the list and enumerate the remainder of them in a grant message. By my reading, this is basically the solution that advocates of not using "except" would think is correct. So, if we take that as a forgone conclusion, the real issue isn't how long does it take to process rules with exceptions; rather, the question is: who should expand semantic groups like "engineering?" Does it make sense for the client to download the entire several-hundred-member list from the server, clip one user out of it, and then send it back in a different format, or to send instructions to the server that say, "take this list, remove this discrete list of elements from it, and then install every remaining member as a positive rule"? I think the key here is that you do *not* need to store the rules as "group with exceptions." If it makes your processing model work better, you can trivially expand the group and apply the exceptions when you receive the message at the server -- and then everything is reduced to the list of positive statements that is apparently much easier to implement. Outlawing the ability to say "except" *will* lead to implementations that do the horrifically high-bandwidth "fetch, prune, and upload" client-side exceptions that I describe above -- and, if we don't have any indicated method for that "fetch" phase, then you *will* end up with multiple, uninteroperable implementations. (Think of the case where your client [built into the operating system] and your server are made by the same large corporation that really likes using its own proprietary directory service. Is that the direction we want to drive things?) /a (With apologies to all the Bobs out there) > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Friday, November 07, 2003 8:15 > To: Naoko ITO > Cc: Simple WG; geopriv@ietf.org > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > As I recall: at the interim meeting in September we were > fortunate to > have two people in attendance that had implemented similar access > systems. It was their opinion that the 'except' clause adds enough > processing to be a scalability concern for even moderately loaded > systems. The fastest systems are able to take a set of rules and > process them one after another until there is a hit. > > Naoko ITO wrote: > > > > I don't understand why the except clause in each permission > statement > > should be dismissed while the separate exception list model can be > > supported. > > > > 1) introducing a separate exception list but not supporting it, > > 2) introducing an except clause in each permission but not > supporting > > it. > > Neither do I. But in my opinion, both should be dismissed. > > -andy > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Nov 10 15:30:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11781 for ; Mon, 10 Nov 2003 15:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIfp-00084r-Ss for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 15:30:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKU9nc031048 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 15:30:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIfp-00084h-PI for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:30:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11744; Mon, 10 Nov 2003 15:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIfm-00044n-00; Mon, 10 Nov 2003 15:30:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJIfm-00044k-00; Mon, 10 Nov 2003 15:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIfi-00082h-HR; Mon, 10 Nov 2003 15:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJIfN-00081y-JA for simple@optimus.ietf.org; Mon, 10 Nov 2003 15:29:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11722; Mon, 10 Nov 2003 15:29:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJIfL-000444-00; Mon, 10 Nov 2003 15:29:39 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJIfK-00043O-00; Mon, 10 Nov 2003 15:29:39 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAAKT1Gd011429; Mon, 10 Nov 2003 14:29:02 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 14:29:01 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Andrew Newton'" , Naoko ITO Cc: Simple WG , geopriv@ietf.org Subject: RE: [Geopriv] RE: [Simple] Changes in xcap-auth MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 14:28:59 -0600 The difficult issue here is knowledge of group membership. As has been proposed earlier, the correct way to say "everyone in my buddy list *except* Bob" is to literally have your client send the list of everyone in your buddy list except Bob. For this specific example, I can agree with the approach of "just explicitly grant permissions." Now, if a user wants to semantically say "everyone in engineering at my company except Bob," it gets much more difficult. From a user perspective in this case, what he needs to say is "everyone in engineering except Bob." He doesn't care about the underlying protocol -- that's the behavior he wants, and anything else is broken. To make this model work without an "except" clause, my client would need to have a mechanism to fetch all the engineering users from the corporate directory, remove Bob from the list and enumerate the remainder of them in a grant message. By my reading, this is basically the solution that advocates of not using "except" would think is correct. So, if we take that as a forgone conclusion, the real issue isn't how long does it take to process rules with exceptions; rather, the question is: who should expand semantic groups like "engineering?" Does it make sense for the client to download the entire several-hundred-member list from the server, clip one user out of it, and then send it back in a different format, or to send instructions to the server that say, "take this list, remove this discrete list of elements from it, and then install every remaining member as a positive rule"? I think the key here is that you do *not* need to store the rules as "group with exceptions." If it makes your processing model work better, you can trivially expand the group and apply the exceptions when you receive the message at the server -- and then everything is reduced to the list of positive statements that is apparently much easier to implement. Outlawing the ability to say "except" *will* lead to implementations that do the horrifically high-bandwidth "fetch, prune, and upload" client-side exceptions that I describe above -- and, if we don't have any indicated method for that "fetch" phase, then you *will* end up with multiple, uninteroperable implementations. (Think of the case where your client [built into the operating system] and your server are made by the same large corporation that really likes using its own proprietary directory service. Is that the direction we want to drive things?) /a (With apologies to all the Bobs out there) > -----Original Message----- > From: Andrew Newton [mailto:anewton@ecotroph.net] > Sent: Friday, November 07, 2003 8:15 > To: Naoko ITO > Cc: Simple WG; geopriv@ietf.org > Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth > > > As I recall: at the interim meeting in September we were > fortunate to > have two people in attendance that had implemented similar access > systems. It was their opinion that the 'except' clause adds enough > processing to be a scalability concern for even moderately loaded > systems. The fastest systems are able to take a set of rules and > process them one after another until there is a hit. > > Naoko ITO wrote: > > > > I don't understand why the except clause in each permission > statement > > should be dismissed while the separate exception list model can be > > supported. > > > > 1) introducing a separate exception list but not supporting it, > > 2) introducing an except clause in each permission but not > supporting > > it. > > Neither do I. But in my opinion, both should be dismissed. > > -andy > > > _______________________________________________ > 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-admin@ietf.org Mon Nov 10 15:55:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13046; Mon, 10 Nov 2003 15:55:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ43-0004VN-00; Mon, 10 Nov 2003 15:55:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJ42-0004VK-00; Mon, 10 Nov 2003 15:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ3u-0001nn-4c; Mon, 10 Nov 2003 15:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ2v-0001j2-Ex for simple@optimus.ietf.org; Mon, 10 Nov 2003 15:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13003 for ; Mon, 10 Nov 2003 15:53:48 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2t-0004UI-00 for simple@ietf.org; Mon, 10 Nov 2003 15:53:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2s-0004UF-00 for simple@ietf.org; Mon, 10 Nov 2003 15:53:59 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAKrwJ17425 for ; Mon, 10 Nov 2003 22:53:58 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 22:53:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 22:53:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 Thread-Index: AcOlUunbv5kOfUClRfywxq0Z12U3OQCd5iEg To: Cc: X-OriginalArrivalTime: 10 Nov 2003 20:53:58.0579 (UTC) FILETIME=[C3271030:01C3A7CC] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 22:53:57 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, November 07, 2003 7:16 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 >=20 >=20 > Hi--I addressed some points in separate emails. Others inline: >=20 > hisham.khartabil@nokia.com wrote: >=20 > [...] >=20 > > - Section 4:=20 [snip] >=20 > > - This section also talks about inactivity timer, and=20 > says that that hosting device invalidates the session state=20 > when timer expires. Why is it just the hosting device? >=20 > Let me turn that question around. Why would any other device need to?=20 > When the hosting device closes the session, the endpoints=20 > will learn of=20 > it in short order as they get their connections closed. So will a=20 > visiting relay, for that matter (although I do think we have an open=20 > item on whether visiting relays should have to worry about the timer.) Why does the visiting peer have an inactivity timer then? It also needs = to clear up state on its end when the timer fires. >=20 > >=20 > > - Section 5.1: > > - Is this section normative? It have normative text like=20 > SHOULD and SHOULD not. >=20 > Yes, section 5.1 is intended to be normative, although it contains no=20 > statements stronger than SHOULD. But we mean those SHOULDs=20 > just as much=20 > as any other SHOULDs in the document. :-) maybe those SHOULDs and SHOULD NOTs should be changed to lower case :) >=20 > >=20 > > - Section 5.2: > > - Open issue: the attribute accept-type can be used to=20 > restrict the use of a message session. So if a session was=20 > created to send mpeg video. The accept-types attribute should=20 > only carry that mime-type. In this way, the other endpoint=20 > does not use that session to send normal messages. >=20 > That is an interesting approach. But I think we may have overlap in=20 > types that are allowed on an IM session, and types that are=20 > allowed on a=20 > file transfer session. What if I want to transfer a large=20 > file of type=20 > text/plain? Excuse my ignorance, but don't files have their own mime-type = text/something? [snip] >=20 > >=20 > > - Section 6.1: > > - The example is missing the accept-types attribute. >=20 > The example in 6.1 is explicitly just an m-line, not an=20 > entire SDP document. But the text above the example indicates that the example shows the = accept types. >=20 > >=20 > > - Section 6.3: > > - the BNF provided allows accept-types to have multiple=20 > *. eg: a=3Daccept-types: * * * > > It should be fixed to something like:=20 > >=20 > > accept-types =3D accept-types-label ":"=20 > format-list > > accept-types-label =3D "accept-types" > > format-list =3D "*" / format-entries > > format-entries =3D format-entry *( SP = format-entry) > > format-entry =3D (type "/" subtype) > > type =3D token > > subtype =3D token > >=20 >=20 > That does not seem to allow for something like "a=3Daccept-types:=20 > message/cpim text/plain *", which is semantically meaningful. I can=20 > change the syntax to only allow one "*", but do we really=20 > care? "* * *"=20 > may be silly, but it can still be interpreted reasonably. what does it mean to say "a=3Daccept-types: message/cpim text/plain *" ? = * is enough in this case and encapsulates message/cpim and text/plain. >=20 > [...] >=20 > > - Section 7.1.2: > > - Why is there text describing the use of SRV if no port=20 > is present? The port is mandatory and therefore resolving=20 > should fail if no port is present. INVITE requests would then=20 > be rejected. If we want SRV, then we need to relax the MUST for port. > >=20 >=20 > It is not mandatory for a URL that designates a relay that is=20 > handed to=20 > an endpoint out-of-band. (For example, when a user configures=20 > a client=20 > to use a relay.) Section 7.1 says:=20 "An MSRP URL server part identifies the hosting device of an MSRP session. If the server part contains a numeric IP address, it MUST also contain a port" So maybe you need to add text differentiating between a relay URL and a = session URL. /Hisham=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 15:55:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13066 for ; Mon, 10 Nov 2003 15:55:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ48-0001vC-VW for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 15:55:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAKtGhi007386 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 15:55:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ48-0001v3-O4 for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 15:55:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13046; Mon, 10 Nov 2003 15:55:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ43-0004VN-00; Mon, 10 Nov 2003 15:55:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJ42-0004VK-00; Mon, 10 Nov 2003 15:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ3u-0001nn-4c; Mon, 10 Nov 2003 15:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJ2v-0001j2-Ex for simple@optimus.ietf.org; Mon, 10 Nov 2003 15:54:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13003 for ; Mon, 10 Nov 2003 15:53:48 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2t-0004UI-00 for simple@ietf.org; Mon, 10 Nov 2003 15:53:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJJ2s-0004UF-00 for simple@ietf.org; Mon, 10 Nov 2003 15:53:59 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAKrwJ17425 for ; Mon, 10 Nov 2003 22:53:58 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 22:53:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 22:53:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 Thread-Index: AcOlUunbv5kOfUClRfywxq0Z12U3OQCd5iEg To: Cc: X-OriginalArrivalTime: 10 Nov 2003 20:53:58.0579 (UTC) FILETIME=[C3271030:01C3A7CC] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 22:53:57 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Friday, November 07, 2003 7:16 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 >=20 >=20 > Hi--I addressed some points in separate emails. Others inline: >=20 > hisham.khartabil@nokia.com wrote: >=20 > [...] >=20 > > - Section 4:=20 [snip] >=20 > > - This section also talks about inactivity timer, and=20 > says that that hosting device invalidates the session state=20 > when timer expires. Why is it just the hosting device? >=20 > Let me turn that question around. Why would any other device need to?=20 > When the hosting device closes the session, the endpoints=20 > will learn of=20 > it in short order as they get their connections closed. So will a=20 > visiting relay, for that matter (although I do think we have an open=20 > item on whether visiting relays should have to worry about the timer.) Why does the visiting peer have an inactivity timer then? It also needs = to clear up state on its end when the timer fires. >=20 > >=20 > > - Section 5.1: > > - Is this section normative? It have normative text like=20 > SHOULD and SHOULD not. >=20 > Yes, section 5.1 is intended to be normative, although it contains no=20 > statements stronger than SHOULD. But we mean those SHOULDs=20 > just as much=20 > as any other SHOULDs in the document. :-) maybe those SHOULDs and SHOULD NOTs should be changed to lower case :) >=20 > >=20 > > - Section 5.2: > > - Open issue: the attribute accept-type can be used to=20 > restrict the use of a message session. So if a session was=20 > created to send mpeg video. The accept-types attribute should=20 > only carry that mime-type. In this way, the other endpoint=20 > does not use that session to send normal messages. >=20 > That is an interesting approach. But I think we may have overlap in=20 > types that are allowed on an IM session, and types that are=20 > allowed on a=20 > file transfer session. What if I want to transfer a large=20 > file of type=20 > text/plain? Excuse my ignorance, but don't files have their own mime-type = text/something? [snip] >=20 > >=20 > > - Section 6.1: > > - The example is missing the accept-types attribute. >=20 > The example in 6.1 is explicitly just an m-line, not an=20 > entire SDP document. But the text above the example indicates that the example shows the = accept types. >=20 > >=20 > > - Section 6.3: > > - the BNF provided allows accept-types to have multiple=20 > *. eg: a=3Daccept-types: * * * > > It should be fixed to something like:=20 > >=20 > > accept-types =3D accept-types-label ":"=20 > format-list > > accept-types-label =3D "accept-types" > > format-list =3D "*" / format-entries > > format-entries =3D format-entry *( SP = format-entry) > > format-entry =3D (type "/" subtype) > > type =3D token > > subtype =3D token > >=20 >=20 > That does not seem to allow for something like "a=3Daccept-types:=20 > message/cpim text/plain *", which is semantically meaningful. I can=20 > change the syntax to only allow one "*", but do we really=20 > care? "* * *"=20 > may be silly, but it can still be interpreted reasonably. what does it mean to say "a=3Daccept-types: message/cpim text/plain *" ? = * is enough in this case and encapsulates message/cpim and text/plain. >=20 > [...] >=20 > > - Section 7.1.2: > > - Why is there text describing the use of SRV if no port=20 > is present? The port is mandatory and therefore resolving=20 > should fail if no port is present. INVITE requests would then=20 > be rejected. If we want SRV, then we need to relax the MUST for port. > >=20 >=20 > It is not mandatory for a URL that designates a relay that is=20 > handed to=20 > an endpoint out-of-band. (For example, when a user configures=20 > a client=20 > to use a relay.) Section 7.1 says:=20 "An MSRP URL server part identifies the hosting device of an MSRP session. If the server part contains a numeric IP address, it MUST also contain a port" So maybe you need to add text differentiating between a relay URL and a = session URL. /Hisham=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 16:03:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13433; Mon, 10 Nov 2003 16:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJCc-0004ds-00; Mon, 10 Nov 2003 16:04:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJCc-0004dp-00; Mon, 10 Nov 2003 16:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJCb-0002Wb-9L; Mon, 10 Nov 2003 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJBt-0002Vd-V3 for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13415 for ; Mon, 10 Nov 2003 16:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJBs-0004dH-00 for simple@ietf.org; Mon, 10 Nov 2003 16:03:16 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJJBr-0004dE-00 for simple@ietf.org; Mon, 10 Nov 2003 16:03:15 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAL2vIc058727; Mon, 10 Nov 2003 15:03:09 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAFFD00.2060107@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB7017973AA@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973AA@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:02:56 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, November 07, 2003 7:16 PM >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 >> >> >>Hi--I addressed some points in separate emails. Others inline: >> >>hisham.khartabil@nokia.com wrote: >> >>[...] >> >> >>>- Section 4: > > [snip] > >>> - This section also talks about inactivity timer, and >> >>says that that hosting device invalidates the session state >>when timer expires. Why is it just the hosting device? >> >>Let me turn that question around. Why would any other device need to? >>When the hosting device closes the session, the endpoints >>will learn of >>it in short order as they get their connections closed. So will a >>visiting relay, for that matter (although I do think we have an open >>item on whether visiting relays should have to worry about the timer.) > > > Why does the visiting peer have an inactivity timer then? It also needs to clear up state on its end when the timer fires. > It needs it so that it knows when and if it needs to send traffic to avoid having the host device kill the session. > >>>- Section 5.1: >>> - Is this section normative? It have normative text like >> >>SHOULD and SHOULD not. >> >>Yes, section 5.1 is intended to be normative, although it contains no >>statements stronger than SHOULD. But we mean those SHOULDs >>just as much >>as any other SHOULDs in the document. :-) > > > > maybe those SHOULDs and SHOULD NOTs should be changed to lower case :) > I am not sure of the point. You are suggesting they should not be normative? Why? > >>>- Section 5.2: >>> - Open issue: the attribute accept-type can be used to >> >>restrict the use of a message session. So if a session was >>created to send mpeg video. The accept-types attribute should >>only carry that mime-type. In this way, the other endpoint >>does not use that session to send normal messages. >> >>That is an interesting approach. But I think we may have overlap in >>types that are allowed on an IM session, and types that are >>allowed on a >>file transfer session. What if I want to transfer a large >>file of type >>text/plain? > > > Excuse my ignorance, but don't files have their own mime-type text/something? > It may be my own ignorance speaking, but I would expect a text file to have a mime type of text/plain. Which is also a reasonable type for an IM. > [snip] > >>>- Section 6.1: >>> - The example is missing the accept-types attribute. >> >>The example in 6.1 is explicitly just an m-line, not an >>entire SDP document. > > > But the text above the example indicates that the example shows the accept types. > > >>>- Section 6.3: >>> - the BNF provided allows accept-types to have multiple >> >>*. eg: a=accept-types: * * * >> >>> It should be fixed to something like: >>> >>> accept-types = accept-types-label ":" >> >>format-list >> >>> accept-types-label = "accept-types" >>> format-list = "*" / format-entries >>> format-entries = format-entry *( SP format-entry) >>> format-entry = (type "/" subtype) >>> type = token >>> subtype = token >>> >> >>That does not seem to allow for something like "a=accept-types: >>message/cpim text/plain *", which is semantically meaningful. I can >>change the syntax to only allow one "*", but do we really >>care? "* * *" >>may be silly, but it can still be interpreted reasonably. > > > > what does it mean to say "a=accept-types: message/cpim text/plain *" ? * is enough in this case and encapsulates message/cpim and text/plain. > > >>[...] >> >> >>>- Section 7.1.2: >>> - Why is there text describing the use of SRV if no port >> >>is present? The port is mandatory and therefore resolving >>should fail if no port is present. INVITE requests would then >>be rejected. If we want SRV, then we need to relax the MUST for port. >> >>It is not mandatory for a URL that designates a relay that is >>handed to >>an endpoint out-of-band. (For example, when a user configures >>a client >>to use a relay.) > > > Section 7.1 says: > > "An MSRP URL server part identifies the hosting device of an MSRP > session. If the server part contains a numeric IP address, it MUST > also contain a port" > > So maybe you need to add text differentiating between a relay URL and a session URL. > > > /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 16:04:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13461 for ; Mon, 10 Nov 2003 16:04:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJCf-0002Yd-Ir for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:04:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAL45wf009825 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:04:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJCf-0002YO-FX for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:04:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13433; Mon, 10 Nov 2003 16:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJCc-0004ds-00; Mon, 10 Nov 2003 16:04:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJCc-0004dp-00; Mon, 10 Nov 2003 16:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJCb-0002Wb-9L; Mon, 10 Nov 2003 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJBt-0002Vd-V3 for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:03:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13415 for ; Mon, 10 Nov 2003 16:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJBs-0004dH-00 for simple@ietf.org; Mon, 10 Nov 2003 16:03:16 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJJBr-0004dE-00 for simple@ietf.org; Mon, 10 Nov 2003 16:03:15 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAL2vIc058727; Mon, 10 Nov 2003 15:03:09 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAFFD00.2060107@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB7017973AA@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973AA@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:02:56 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Friday, November 07, 2003 7:16 PM >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 >> >> >>Hi--I addressed some points in separate emails. Others inline: >> >>hisham.khartabil@nokia.com wrote: >> >>[...] >> >> >>>- Section 4: > > [snip] > >>> - This section also talks about inactivity timer, and >> >>says that that hosting device invalidates the session state >>when timer expires. Why is it just the hosting device? >> >>Let me turn that question around. Why would any other device need to? >>When the hosting device closes the session, the endpoints >>will learn of >>it in short order as they get their connections closed. So will a >>visiting relay, for that matter (although I do think we have an open >>item on whether visiting relays should have to worry about the timer.) > > > Why does the visiting peer have an inactivity timer then? It also needs to clear up state on its end when the timer fires. > It needs it so that it knows when and if it needs to send traffic to avoid having the host device kill the session. > >>>- Section 5.1: >>> - Is this section normative? It have normative text like >> >>SHOULD and SHOULD not. >> >>Yes, section 5.1 is intended to be normative, although it contains no >>statements stronger than SHOULD. But we mean those SHOULDs >>just as much >>as any other SHOULDs in the document. :-) > > > > maybe those SHOULDs and SHOULD NOTs should be changed to lower case :) > I am not sure of the point. You are suggesting they should not be normative? Why? > >>>- Section 5.2: >>> - Open issue: the attribute accept-type can be used to >> >>restrict the use of a message session. So if a session was >>created to send mpeg video. The accept-types attribute should >>only carry that mime-type. In this way, the other endpoint >>does not use that session to send normal messages. >> >>That is an interesting approach. But I think we may have overlap in >>types that are allowed on an IM session, and types that are >>allowed on a >>file transfer session. What if I want to transfer a large >>file of type >>text/plain? > > > Excuse my ignorance, but don't files have their own mime-type text/something? > It may be my own ignorance speaking, but I would expect a text file to have a mime type of text/plain. Which is also a reasonable type for an IM. > [snip] > >>>- Section 6.1: >>> - The example is missing the accept-types attribute. >> >>The example in 6.1 is explicitly just an m-line, not an >>entire SDP document. > > > But the text above the example indicates that the example shows the accept types. > > >>>- Section 6.3: >>> - the BNF provided allows accept-types to have multiple >> >>*. eg: a=accept-types: * * * >> >>> It should be fixed to something like: >>> >>> accept-types = accept-types-label ":" >> >>format-list >> >>> accept-types-label = "accept-types" >>> format-list = "*" / format-entries >>> format-entries = format-entry *( SP format-entry) >>> format-entry = (type "/" subtype) >>> type = token >>> subtype = token >>> >> >>That does not seem to allow for something like "a=accept-types: >>message/cpim text/plain *", which is semantically meaningful. I can >>change the syntax to only allow one "*", but do we really >>care? "* * *" >>may be silly, but it can still be interpreted reasonably. > > > > what does it mean to say "a=accept-types: message/cpim text/plain *" ? * is enough in this case and encapsulates message/cpim and text/plain. > > >>[...] >> >> >>>- Section 7.1.2: >>> - Why is there text describing the use of SRV if no port >> >>is present? The port is mandatory and therefore resolving >>should fail if no port is present. INVITE requests would then >>be rejected. If we want SRV, then we need to relax the MUST for port. >> >>It is not mandatory for a URL that designates a relay that is >>handed to >>an endpoint out-of-band. (For example, when a user configures >>a client >>to use a relay.) > > > Section 7.1 says: > > "An MSRP URL server part identifies the hosting device of an MSRP > session. If the server part contains a numeric IP address, it MUST > also contain a port" > > So maybe you need to add text differentiating between a relay URL and a session URL. > > > /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 16:30:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14415; Mon, 10 Nov 2003 16:30:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJcs-00051e-00; Mon, 10 Nov 2003 16:31:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJcs-00051b-00; Mon, 10 Nov 2003 16:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJck-0004RP-Hw; Mon, 10 Nov 2003 16:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJcO-0004QZ-U3 for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14402 for ; Mon, 10 Nov 2003 16:30:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJcM-00051F-00 for simple@ietf.org; Mon, 10 Nov 2003 16:30:38 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJJcM-00051C-00 for simple@ietf.org; Mon, 10 Nov 2003 16:30:38 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAALUbJ21619 for ; Mon, 10 Nov 2003 23:30:37 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 23:30:36 +0200 Received: from nokia.com ([10.241.55.183]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Nov 2003 23:30:34 +0200 Message-ID: <3FB00377.20005@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> <3FAFC623.6000700@dynamicsoft.com> In-Reply-To: <3FAFC623.6000700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2003 21:30:35.0429 (UTC) FILETIME=[E093C550:01C3A7D1] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 23:30:31 +0200 Content-Transfer-Encoding: 7bit Hi, At this point I'm really confused about the true meaning for TR-ID. The current draft reads to me that the TR-ID should be unique within a session, but there still isn't any duplicate suppression on the recipient side. If this is the case, I don't even see why TR-ID needs to be unique within a session. It would seem enough for the sender not to have TR-ID collisions occur within the set of *pending* requests. in other words, the TR-ID is opaque to the recipient - whatever the request had is used in the response. Having said that, I think TR-ID is not working to its full potential, and thus I have a new proposal. Let's make TR-ID a simple counter. Each session starts from zero, and each new message increments this counter. We can come up with a reasonable resolution for this counter; x seems as good a value as any. When the counter hits x, it is reset to zero. The good thing is that we get duplicate detection without the recipient having to remember all used TR-IDs within a session, but it suffices to maintain this unidirectional counter on each end. Whatever the resolution will be, it seems a reasonable limitation to say that a sender can only have x pending requests at a time. Cheers, Aki ext Ben Campbell wrote: > Paul Kyzivat wrote: > > [...] > >> >> I'm not certain a time period is really necessary. I think this can be >> local option. >> >> Even uniqueness across streams isn't *required*, though it would be >> helpful. Instead, we can simply introduce an error response to be used >> when a duplicate is detected and supressed. If it was supressed in >> error because the sender duplicated a TR-ID from another stream, the >> sender would then know to recover. >> >> But I agree that some further clarification on TR-ID uniqueness could >> be helpful. >> > > If TR-ID is not required to be unique across sessions, and you allow > clients to attempt to find duplicate messages using TR-ID across > sessions, then you introduce the possibility of false detection caused > by TR-ID collisions. This seems bad to me. > > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Nov 10 16:31:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14450 for ; Mon, 10 Nov 2003 16:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJcw-0004WO-D0 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:31:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALVEFv017380 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:31:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJcw-0004WF-8Q for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:31:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14415; Mon, 10 Nov 2003 16:30:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJcs-00051e-00; Mon, 10 Nov 2003 16:31:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJJcs-00051b-00; Mon, 10 Nov 2003 16:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJck-0004RP-Hw; Mon, 10 Nov 2003 16:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJcO-0004QZ-U3 for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14402 for ; Mon, 10 Nov 2003 16:30:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJcM-00051F-00 for simple@ietf.org; Mon, 10 Nov 2003 16:30:38 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJJcM-00051C-00 for simple@ietf.org; Mon, 10 Nov 2003 16:30:38 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAALUbJ21619 for ; Mon, 10 Nov 2003 23:30:37 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Nov 2003 23:30:36 +0200 Received: from nokia.com ([10.241.55.183]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 10 Nov 2003 23:30:34 +0200 Message-ID: <3FB00377.20005@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> <3FAFC623.6000700@dynamicsoft.com> In-Reply-To: <3FAFC623.6000700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2003 21:30:35.0429 (UTC) FILETIME=[E093C550:01C3A7D1] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 23:30:31 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, At this point I'm really confused about the true meaning for TR-ID. The current draft reads to me that the TR-ID should be unique within a session, but there still isn't any duplicate suppression on the recipient side. If this is the case, I don't even see why TR-ID needs to be unique within a session. It would seem enough for the sender not to have TR-ID collisions occur within the set of *pending* requests. in other words, the TR-ID is opaque to the recipient - whatever the request had is used in the response. Having said that, I think TR-ID is not working to its full potential, and thus I have a new proposal. Let's make TR-ID a simple counter. Each session starts from zero, and each new message increments this counter. We can come up with a reasonable resolution for this counter; x seems as good a value as any. When the counter hits x, it is reset to zero. The good thing is that we get duplicate detection without the recipient having to remember all used TR-IDs within a session, but it suffices to maintain this unidirectional counter on each end. Whatever the resolution will be, it seems a reasonable limitation to say that a sender can only have x pending requests at a time. Cheers, Aki ext Ben Campbell wrote: > Paul Kyzivat wrote: > > [...] > >> >> I'm not certain a time period is really necessary. I think this can be >> local option. >> >> Even uniqueness across streams isn't *required*, though it would be >> helpful. Instead, we can simply introduce an error response to be used >> when a duplicate is detected and supressed. If it was supressed in >> error because the sender duplicated a TR-ID from another stream, the >> sender would then know to recover. >> >> But I agree that some further clarification on TR-ID uniqueness could >> be helpful. >> > > If TR-ID is not required to be unique across sessions, and you allow > clients to attempt to find duplicate messages using TR-ID across > sessions, then you introduce the possibility of false detection caused > by TR-ID collisions. This seems bad to me. > > > > _______________________________________________ > 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-admin@ietf.org Mon Nov 10 16:54:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15533; Mon, 10 Nov 2003 16:54:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK05-0005Rq-00; Mon, 10 Nov 2003 16:55:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJK05-0005Rn-00; Mon, 10 Nov 2003 16:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJzz-0006yR-DL; Mon, 10 Nov 2003 16:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJza-0006xH-6B for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:54:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15502; Mon, 10 Nov 2003 16:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJzW-0005RP-00; Mon, 10 Nov 2003 16:54:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJJzV-0005R2-00; Mon, 10 Nov 2003 16:54:33 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAALqFca014976; Mon, 10 Nov 2003 16:52:16 -0500 (EST) Message-ID: <3FB0088F.5070602@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Markus.Isomaki@nokia.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <3FAE8B6A.7070101@cs.columbia.edu> <3FAF294D.3010308@dynamicsoft.com> <3FAFEAFF.10601@cs.columbia.edu> In-Reply-To: <3FAFEAFF.10601@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 16:52:15 -0500 Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> I agree that groups are a separate issue. >> >> However, in xcap, it currently does allow for things like "applies to >> everyone on golf-list, but Joe". It does that by having each group >> defined by an xcap resource (i.e., an http URI) that can be used to >> fetch the group list. Then, membership in the group is determined by >> authenticating as one of the identities in that group. >> >> If you can't fetch the list, the permission isnt granted, and thus its >> privacy safe. > > > Clearly, fetching group lists adds significant complexity: expiration > (presumably you don't want to fetch it every time) and the inability, > without significant overhead, to implement a permission system using any > reasonably efficient query mechanism. I think the required functionality should drive the protocol choices and implementation, not the other way around. That said, it is certainly possible to have efficient implementations of policies that involve an external fetch of a group. This is not a radically new concept. You can do a really good job at it when the lists are in the same administrative domain as the location server, as then you can in fact do various kinds of cached optimizations. > >> >> If, for some reason, a user specifies a rule based on a list in >> another domain, with members in other domains, the server can't >> authenticate those users, and thus permissions are not granted, and >> thus its privacy safe. >> >> You *would* have problems if you could have an exception defined by an >> external list, but I agree we shouldnt do that. >> >> So, given this design and assumptions, I dont see a problem with >> groups per se. There is a scope question, but I dont see a technical >> problem. > > > It just makes efficient implementation difficult to impossible. As I mentioned above, this is not a radically new capability. Policies based on external lists are not a new concept. That said, I would be willing to buy that this is out of scope for the initial revision of the specs. > I would also like to get consensus to rule out random wildcard matching > and, less importantly, domain exceptions. Thus, > > applies-to: foo.*.example.com > > and > > applies-to: example.com > except cs.example.com > > seem far less useful and add significant complexity. Agreed these are out of scope. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 16:55:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15591 for ; Mon, 10 Nov 2003 16:55:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK09-00071g-6N for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:55:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALtD7N027007 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK09-00071W-3N for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:55:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15533; Mon, 10 Nov 2003 16:54:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK05-0005Rq-00; Mon, 10 Nov 2003 16:55:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJK05-0005Rn-00; Mon, 10 Nov 2003 16:55:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJzz-0006yR-DL; Mon, 10 Nov 2003 16:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJJza-0006xH-6B for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:54:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15502; Mon, 10 Nov 2003 16:54:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJzW-0005RP-00; Mon, 10 Nov 2003 16:54:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AJJzV-0005R2-00; Mon, 10 Nov 2003 16:54:33 -0500 Received: from dynamicsoft.com ([63.113.46.36]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAALqFca014976; Mon, 10 Nov 2003 16:52:16 -0500 (EST) Message-ID: <3FB0088F.5070602@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Markus.Isomaki@nokia.com, anewton@ecotroph.net, naoko@netlab.nec.co.jp, simple@ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] RE: [Simple] Changes in xcap-auth References: <3FAE8B6A.7070101@cs.columbia.edu> <3FAF294D.3010308@dynamicsoft.com> <3FAFEAFF.10601@cs.columbia.edu> In-Reply-To: <3FAFEAFF.10601@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 16:52:15 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > Jonathan Rosenberg wrote: > >> I agree that groups are a separate issue. >> >> However, in xcap, it currently does allow for things like "applies to >> everyone on golf-list, but Joe". It does that by having each group >> defined by an xcap resource (i.e., an http URI) that can be used to >> fetch the group list. Then, membership in the group is determined by >> authenticating as one of the identities in that group. >> >> If you can't fetch the list, the permission isnt granted, and thus its >> privacy safe. > > > Clearly, fetching group lists adds significant complexity: expiration > (presumably you don't want to fetch it every time) and the inability, > without significant overhead, to implement a permission system using any > reasonably efficient query mechanism. I think the required functionality should drive the protocol choices and implementation, not the other way around. That said, it is certainly possible to have efficient implementations of policies that involve an external fetch of a group. This is not a radically new concept. You can do a really good job at it when the lists are in the same administrative domain as the location server, as then you can in fact do various kinds of cached optimizations. > >> >> If, for some reason, a user specifies a rule based on a list in >> another domain, with members in other domains, the server can't >> authenticate those users, and thus permissions are not granted, and >> thus its privacy safe. >> >> You *would* have problems if you could have an exception defined by an >> external list, but I agree we shouldnt do that. >> >> So, given this design and assumptions, I dont see a problem with >> groups per se. There is a scope question, but I dont see a technical >> problem. > > > It just makes efficient implementation difficult to impossible. As I mentioned above, this is not a radically new capability. Policies based on external lists are not a new concept. That said, I would be willing to buy that this is out of scope for the initial revision of the specs. > I would also like to get consensus to rule out random wildcard matching > and, less importantly, domain exceptions. Thus, > > applies-to: foo.*.example.com > > and > > applies-to: example.com > except cs.example.com > > seem far less useful and add significant complexity. Agreed these are out of scope. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 16:55:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15607; Mon, 10 Nov 2003 16:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK0v-0005SL-00; Mon, 10 Nov 2003 16:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJK0u-0005SI-00; Mon, 10 Nov 2003 16:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK0v-00075P-ID; Mon, 10 Nov 2003 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK0a-00074B-Vs for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:55:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15588 for ; Mon, 10 Nov 2003 16:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK0Y-0005SB-00 for simple@ietf.org; Mon, 10 Nov 2003 16:55:38 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJK0X-0005S8-00 for simple@ietf.org; Mon, 10 Nov 2003 16:55:37 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAALtRIc062979; Mon, 10 Nov 2003 15:55:28 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB0094E.5040101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> <3FAFC623.6000700@dynamicsoft.com> <3FB00377.20005@nokia.com> In-Reply-To: <3FB00377.20005@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:55:26 -0600 Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > At this point I'm really confused about the true meaning for TR-ID. > > The current draft reads to me that the TR-ID should be unique within a > session, but there still isn't any duplicate suppression on the > recipient side. If this is the case, I don't even see why TR-ID needs to > be unique within a session. It would seem enough for the sender not to > have TR-ID collisions occur within the set of *pending* requests. in > other words, the TR-ID is opaque to the recipient - whatever the request > had is used in the response. The real requirement for the current usage is exactly as you say, that is, no collisions within the set of pending requests. Making them unique inside a session simply seemed the easiest way to enforce this. > > Having said that, I think TR-ID is not working to its full potential, > and thus I have a new proposal. > > Let's make TR-ID a simple counter. Each session starts from zero, and > each new message increments this counter. We can come up with a > reasonable resolution for this counter; x seems as good a value as any. > When the counter hits x, it is reset to zero. > The good thing is that we get duplicate detection without the recipient > having to remember all used TR-IDs within a session, but it suffices to > maintain this unidirectional counter on each end. > > Whatever the resolution will be, it seems a reasonable limitation to say > that a sender can only have x pending requests at a time. This is interesting. We originally avoided this approach due to potential problems with shared connections, etc. These problems may all be gone with the current version. One potential problem comes to mind is, if TR-ID 2 times out _and_ was never presented to the recipient, TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may falsely be treated as a duplicate. Now, I am not sure this can really happen assuming TCP connections all the way. If the receiving peer is overloaded, but recovers well enough to process TR-ID 3, then TR-ID 2 will most likely get processed first anyway, wouldn't it? Does anyone recall a problem with requiring ordered, contiguous TR-ID values, and allowing the receiving peer to notice discrepancies, that is still relevant? > > Cheers, > Aki > > ext Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >> [...] >> >>> >>> I'm not certain a time period is really necessary. I think this can >>> be local option. >>> >>> Even uniqueness across streams isn't *required*, though it would be >>> helpful. Instead, we can simply introduce an error response to be >>> used when a duplicate is detected and supressed. If it was supressed >>> in error because the sender duplicated a TR-ID from another stream, >>> the sender would then know to recover. >>> >>> But I agree that some further clarification on TR-ID uniqueness could >>> be helpful. >>> >> >> If TR-ID is not required to be unique across sessions, and you allow >> clients to attempt to find duplicate messages using TR-ID across >> sessions, then you introduce the possibility of false detection caused >> by TR-ID collisions. This seems bad to me. >> >> >> >> _______________________________________________ >> 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 exim@www1.ietf.org Mon Nov 10 16:56:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15638 for ; Mon, 10 Nov 2003 16:56:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK0y-00079F-MN for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAALu4kn027466 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 16:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK0y-00078s-EC for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 16:56:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15607; Mon, 10 Nov 2003 16:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK0v-0005SL-00; Mon, 10 Nov 2003 16:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJK0u-0005SI-00; Mon, 10 Nov 2003 16:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK0v-00075P-ID; Mon, 10 Nov 2003 16:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJK0a-00074B-Vs for simple@optimus.ietf.org; Mon, 10 Nov 2003 16:55:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15588 for ; Mon, 10 Nov 2003 16:55:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJK0Y-0005SB-00 for simple@ietf.org; Mon, 10 Nov 2003 16:55:38 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJK0X-0005S8-00 for simple@ietf.org; Mon, 10 Nov 2003 16:55:37 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAALtRIc062979; Mon, 10 Nov 2003 15:55:28 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB0094E.5040101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> <3FAFC623.6000700@dynamicsoft.com> <3FB00377.20005@nokia.com> In-Reply-To: <3FB00377.20005@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 15:55:26 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Aki Niemi wrote: > Hi, > > At this point I'm really confused about the true meaning for TR-ID. > > The current draft reads to me that the TR-ID should be unique within a > session, but there still isn't any duplicate suppression on the > recipient side. If this is the case, I don't even see why TR-ID needs to > be unique within a session. It would seem enough for the sender not to > have TR-ID collisions occur within the set of *pending* requests. in > other words, the TR-ID is opaque to the recipient - whatever the request > had is used in the response. The real requirement for the current usage is exactly as you say, that is, no collisions within the set of pending requests. Making them unique inside a session simply seemed the easiest way to enforce this. > > Having said that, I think TR-ID is not working to its full potential, > and thus I have a new proposal. > > Let's make TR-ID a simple counter. Each session starts from zero, and > each new message increments this counter. We can come up with a > reasonable resolution for this counter; x seems as good a value as any. > When the counter hits x, it is reset to zero. > The good thing is that we get duplicate detection without the recipient > having to remember all used TR-IDs within a session, but it suffices to > maintain this unidirectional counter on each end. > > Whatever the resolution will be, it seems a reasonable limitation to say > that a sender can only have x pending requests at a time. This is interesting. We originally avoided this approach due to potential problems with shared connections, etc. These problems may all be gone with the current version. One potential problem comes to mind is, if TR-ID 2 times out _and_ was never presented to the recipient, TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may falsely be treated as a duplicate. Now, I am not sure this can really happen assuming TCP connections all the way. If the receiving peer is overloaded, but recovers well enough to process TR-ID 3, then TR-ID 2 will most likely get processed first anyway, wouldn't it? Does anyone recall a problem with requiring ordered, contiguous TR-ID values, and allowing the receiving peer to notice discrepancies, that is still relevant? > > Cheers, > Aki > > ext Ben Campbell wrote: > >> Paul Kyzivat wrote: >> >> [...] >> >>> >>> I'm not certain a time period is really necessary. I think this can >>> be local option. >>> >>> Even uniqueness across streams isn't *required*, though it would be >>> helpful. Instead, we can simply introduce an error response to be >>> used when a duplicate is detected and supressed. If it was supressed >>> in error because the sender duplicated a TR-ID from another stream, >>> the sender would then know to recover. >>> >>> But I agree that some further clarification on TR-ID uniqueness could >>> be helpful. >>> >> >> If TR-ID is not required to be unique across sessions, and you allow >> clients to attempt to find duplicate messages using TR-ID across >> sessions, then you introduce the possibility of false detection caused >> by TR-ID collisions. This seems bad to me. >> >> >> >> _______________________________________________ >> 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-admin@ietf.org Mon Nov 10 17:26:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17525; Mon, 10 Nov 2003 17:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKUz-00068A-00; Mon, 10 Nov 2003 17:27:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKUy-000687-00; Mon, 10 Nov 2003 17:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKUv-0001Wb-JW; Mon, 10 Nov 2003 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKUS-0001SG-1L for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:26:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17482 for ; Mon, 10 Nov 2003 17:26:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKUP-00067X-00 for simple@ietf.org; Mon, 10 Nov 2003 17:26:29 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJKUO-00067U-00 for simple@ietf.org; Mon, 10 Nov 2003 17:26:28 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAMQJIc065821; Mon, 10 Nov 2003 16:26:25 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB0108A.1000806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 16:26:18 -0600 Content-Transfer-Encoding: 7bit I like this approach alot. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > >>(3) its a CID URI, referring to the list in the body of the request > > > That has the potential to make routing very difficult. If the first proxy > that you hit doesn't know what the cid scheme means, then things won't work. > It seems to me that the most flexible approach would be something like: > > SUBSCRIBE sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > Nice thing about this is that you could also do something like: > > SUBSCRIBE > sip:group@example.com;list=http://xcap.example.com/services/presence-lists/u > sers/bill/fr.xml SIP/2.0 > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 17:27:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17589 for ; Mon, 10 Nov 2003 17:27:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKV2-0001YE-NY for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:27:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMR8ws005956 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKV2-0001Xz-I3 for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:27:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17525; Mon, 10 Nov 2003 17:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKUz-00068A-00; Mon, 10 Nov 2003 17:27:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKUy-000687-00; Mon, 10 Nov 2003 17:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKUv-0001Wb-JW; Mon, 10 Nov 2003 17:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKUS-0001SG-1L for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:26:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17482 for ; Mon, 10 Nov 2003 17:26:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKUP-00067X-00 for simple@ietf.org; Mon, 10 Nov 2003 17:26:29 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJKUO-00067U-00 for simple@ietf.org; Mon, 10 Nov 2003 17:26:28 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAAMQJIc065821; Mon, 10 Nov 2003 16:26:25 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB0108A.1000806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: Jonathan Rosenberg , Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 16:26:18 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like this approach alot. Adam Roach wrote: > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: > > >>(3) its a CID URI, referring to the list in the body of the request > > > That has the potential to make routing very difficult. If the first proxy > that you hit doesn't know what the cid scheme means, then things won't work. > It seems to me that the most flexible approach would be something like: > > SUBSCRIBE sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > Nice thing about this is that you could also do something like: > > SUBSCRIBE > sip:group@example.com;list=http://xcap.example.com/services/presence-lists/u > sers/bill/fr.xml SIP/2.0 > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 17:27:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17651; Mon, 10 Nov 2003 17:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKVr-00069s-00; Mon, 10 Nov 2003 17:27:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKVr-00069m-00; Mon, 10 Nov 2003 17:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKVs-0001f9-MX; Mon, 10 Nov 2003 17:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKVV-0001dw-2W for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:27:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17572 for ; Mon, 10 Nov 2003 17:27:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKVS-00069U-00 for simple@ietf.org; Mon, 10 Nov 2003 17:27:34 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AJKVR-000685-00 for simple@ietf.org; Mon, 10 Nov 2003 17:27:34 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAAMR0mU010787; Mon, 10 Nov 2003 14:27:00 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW50116; Mon, 10 Nov 2003 17:26:59 -0500 (EST) Message-ID: <3FB010B2.7040703@cisco.com> 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: Ben Campbell CC: Aki Niemi , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> <3FAFC623.6000700@dynamicsoft.com> <3FB00377.20005@nokia.com> <3FB0094E.5040101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 17:26:58 -0500 Content-Transfer-Encoding: 7bit Its true that within a given session it should be sufficient to distinguish between the currently pending messages. So TR-IDs for acknowledged messages could be recycled. OTOH, without some tweaks that makes the problem of failing over to another session harder. This could perhaps be handled by making a two-part TR-ID: .. So when a session is established for the first time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to fail over to a new session, then ids for new messages are 2.1, 2.2, ..., but retransmissions of old ones would still carry their original TR-ID. A recipient that supports duplicate suppression would need to remember the ids of messages processed until certain the response had been received by the sender. This could be handled a number of different ways: - reuse of a TR-ID in the *same* session isn't a retransmission. It redefines what message it applies to. - if a request is sent in the other direction, any responses sent prior to it can be inferred to have been received, so the messages corresponding to those responses will no longer be eligible for retransmission. - the timeout interval for messages puts an upper bound on how long one needs to be prepared to deal with retransmissions of a message. Paul Ben Campbell wrote: > Aki Niemi wrote: > >> Hi, >> >> At this point I'm really confused about the true meaning for TR-ID. >> >> The current draft reads to me that the TR-ID should be unique within a >> session, but there still isn't any duplicate suppression on the >> recipient side. If this is the case, I don't even see why TR-ID needs >> to be unique within a session. It would seem enough for the sender not >> to have TR-ID collisions occur within the set of *pending* requests. >> in other words, the TR-ID is opaque to the recipient - whatever the >> request had is used in the response. > > > The real requirement for the current usage is exactly as you say, that > is, no collisions within the set of pending requests. Making them unique > inside a session simply seemed the easiest way to enforce this. > >> >> Having said that, I think TR-ID is not working to its full potential, >> and thus I have a new proposal. >> >> Let's make TR-ID a simple counter. Each session starts from zero, and >> each new message increments this counter. We can come up with a >> reasonable resolution for this counter; x seems as good a value as >> any. When the counter hits x, it is reset to zero. >> The good thing is that we get duplicate detection without the >> recipient having to remember all used TR-IDs within a session, but it >> suffices to maintain this unidirectional counter on each end. >> >> Whatever the resolution will be, it seems a reasonable limitation to >> say that a sender can only have x pending requests at a time. > > > This is interesting. We originally avoided this approach due to > potential problems with shared connections, etc. These problems may all > be gone with the current version. One potential problem comes to mind > is, if TR-ID 2 times out _and_ was never presented to the recipient, > TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may falsely be > treated as a duplicate. Now, I am not sure this can really happen > assuming TCP connections all the way. If the receiving peer is > overloaded, but recovers well enough to process TR-ID 3, then TR-ID 2 > will most likely get processed first anyway, wouldn't it? > > Does anyone recall a problem with requiring ordered, contiguous TR-ID > values, and allowing the receiving peer to notice discrepancies, that is > still relevant? > > >> >> Cheers, >> Aki >> >> ext Ben Campbell wrote: >> >>> Paul Kyzivat wrote: >>> >>> [...] >>> >>>> >>>> I'm not certain a time period is really necessary. I think this can >>>> be local option. >>>> >>>> Even uniqueness across streams isn't *required*, though it would be >>>> helpful. Instead, we can simply introduce an error response to be >>>> used when a duplicate is detected and supressed. If it was supressed >>>> in error because the sender duplicated a TR-ID from another stream, >>>> the sender would then know to recover. >>>> >>>> But I agree that some further clarification on TR-ID uniqueness >>>> could be helpful. >>>> >>> >>> If TR-ID is not required to be unique across sessions, and you allow >>> clients to attempt to find duplicate messages using TR-ID across >>> sessions, then you introduce the possibility of false detection >>> caused by TR-ID collisions. This seems bad to me. >>> >>> >>> >>> _______________________________________________ >>> 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 exim@www1.ietf.org Mon Nov 10 17:28:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17725 for ; Mon, 10 Nov 2003 17:28:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKVv-0001hU-DV for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:28:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMS3lw006530 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKVv-0001hF-9h for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:28:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17651; Mon, 10 Nov 2003 17:27:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKVr-00069s-00; Mon, 10 Nov 2003 17:27:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKVr-00069m-00; Mon, 10 Nov 2003 17:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKVs-0001f9-MX; Mon, 10 Nov 2003 17:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKVV-0001dw-2W for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:27:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17572 for ; Mon, 10 Nov 2003 17:27:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKVS-00069U-00 for simple@ietf.org; Mon, 10 Nov 2003 17:27:34 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AJKVR-000685-00 for simple@ietf.org; Mon, 10 Nov 2003 17:27:34 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAAMR0mU010787; Mon, 10 Nov 2003 14:27:00 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW50116; Mon, 10 Nov 2003 17:26:59 -0500 (EST) Message-ID: <3FB010B2.7040703@cisco.com> 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: Ben Campbell CC: Aki Niemi , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> <3FA94DC6.7020400@cisco.com> <3FAC0D26.4070402@dynamicsoft.com> <3FAC2661.70106@cisco.com> <3FAFC623.6000700@dynamicsoft.com> <3FB00377.20005@nokia.com> <3FB0094E.5040101@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 17:26:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Its true that within a given session it should be sufficient to distinguish between the currently pending messages. So TR-IDs for acknowledged messages could be recycled. OTOH, without some tweaks that makes the problem of failing over to another session harder. This could perhaps be handled by making a two-part TR-ID: .. So when a session is established for the first time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to fail over to a new session, then ids for new messages are 2.1, 2.2, ..., but retransmissions of old ones would still carry their original TR-ID. A recipient that supports duplicate suppression would need to remember the ids of messages processed until certain the response had been received by the sender. This could be handled a number of different ways: - reuse of a TR-ID in the *same* session isn't a retransmission. It redefines what message it applies to. - if a request is sent in the other direction, any responses sent prior to it can be inferred to have been received, so the messages corresponding to those responses will no longer be eligible for retransmission. - the timeout interval for messages puts an upper bound on how long one needs to be prepared to deal with retransmissions of a message. Paul Ben Campbell wrote: > Aki Niemi wrote: > >> Hi, >> >> At this point I'm really confused about the true meaning for TR-ID. >> >> The current draft reads to me that the TR-ID should be unique within a >> session, but there still isn't any duplicate suppression on the >> recipient side. If this is the case, I don't even see why TR-ID needs >> to be unique within a session. It would seem enough for the sender not >> to have TR-ID collisions occur within the set of *pending* requests. >> in other words, the TR-ID is opaque to the recipient - whatever the >> request had is used in the response. > > > The real requirement for the current usage is exactly as you say, that > is, no collisions within the set of pending requests. Making them unique > inside a session simply seemed the easiest way to enforce this. > >> >> Having said that, I think TR-ID is not working to its full potential, >> and thus I have a new proposal. >> >> Let's make TR-ID a simple counter. Each session starts from zero, and >> each new message increments this counter. We can come up with a >> reasonable resolution for this counter; x seems as good a value as >> any. When the counter hits x, it is reset to zero. >> The good thing is that we get duplicate detection without the >> recipient having to remember all used TR-IDs within a session, but it >> suffices to maintain this unidirectional counter on each end. >> >> Whatever the resolution will be, it seems a reasonable limitation to >> say that a sender can only have x pending requests at a time. > > > This is interesting. We originally avoided this approach due to > potential problems with shared connections, etc. These problems may all > be gone with the current version. One potential problem comes to mind > is, if TR-ID 2 times out _and_ was never presented to the recipient, > TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may falsely be > treated as a duplicate. Now, I am not sure this can really happen > assuming TCP connections all the way. If the receiving peer is > overloaded, but recovers well enough to process TR-ID 3, then TR-ID 2 > will most likely get processed first anyway, wouldn't it? > > Does anyone recall a problem with requiring ordered, contiguous TR-ID > values, and allowing the receiving peer to notice discrepancies, that is > still relevant? > > >> >> Cheers, >> Aki >> >> ext Ben Campbell wrote: >> >>> Paul Kyzivat wrote: >>> >>> [...] >>> >>>> >>>> I'm not certain a time period is really necessary. I think this can >>>> be local option. >>>> >>>> Even uniqueness across streams isn't *required*, though it would be >>>> helpful. Instead, we can simply introduce an error response to be >>>> used when a duplicate is detected and supressed. If it was supressed >>>> in error because the sender duplicated a TR-ID from another stream, >>>> the sender would then know to recover. >>>> >>>> But I agree that some further clarification on TR-ID uniqueness >>>> could be helpful. >>>> >>> >>> If TR-ID is not required to be unique across sessions, and you allow >>> clients to attempt to find duplicate messages using TR-ID across >>> sessions, then you introduce the possibility of false detection >>> caused by TR-ID collisions. This seems bad to me. >>> >>> >>> >>> _______________________________________________ >>> 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-admin@ietf.org Mon Nov 10 17:35:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18068; Mon, 10 Nov 2003 17:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKdd-0006KM-00; Mon, 10 Nov 2003 17:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKdd-0006KJ-00; Mon, 10 Nov 2003 17:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKdd-0002MP-AL; Mon, 10 Nov 2003 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKdV-0002Lm-3D for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:35:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18059 for ; Mon, 10 Nov 2003 17:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKdS-0006K4-00 for simple@ietf.org; Mon, 10 Nov 2003 17:35:50 -0500 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AJKdR-0006Jz-00 for simple@ietf.org; Mon, 10 Nov 2003 17:35:50 -0500 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 10 Nov 2003 22:38:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Comments on message-sessions-02 - message retry Message-ID: <45730E094814E44488F789C1CDED27AE0219B103@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOn1Xa/+D+cc2qFTlq8ejhsB+wt6AABLt9H From: "Chris Boulton" To: "Ben Campbell" , "Aki Niemi" Cc: "Paul Kyzivat" , , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 22:35:47 -0000 Content-Transfer-Encoding: base64 VGhpcyBkb2VzIHNlZW0gbGlrZSBhIGNsZWFuZXIgc29sdXRpb24uICBJIHBlcnNvbmFsbHkgZG9u J3Qgc2VlIGFueSBwcm9ibGVtcyB1c2luZyB0aGlzIGFwcHJvYWNoIC4NCiANCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIA0KRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQGR5 bmFtaWNzb2Z0LmNvbV0gDQpTZW50OiBNb24gMTAvMTEvMjAwMyAyMTo1NSANClRvOiBBa2kgTmll bWkgDQpDYzogUGF1bCBLeXppdmF0OyBoaXNoYW0ua2hhcnRhYmlsQG5va2lhLmNvbTsgc2ltcGxl QGlldGYub3JnIA0KU3ViamVjdDogUmU6IFtTaW1wbGVdIENvbW1lbnRzIG9uIG1lc3NhZ2Utc2Vz c2lvbnMtMDIgLSBtZXNzYWdlIHJldHJ5DQoNCg0KDQoJQWtpIE5pZW1pIHdyb3RlOg0KCQ0KCT4g SGksDQoJPg0KCT4gQXQgdGhpcyBwb2ludCBJJ20gcmVhbGx5IGNvbmZ1c2VkIGFib3V0IHRoZSB0 cnVlIG1lYW5pbmcgZm9yIFRSLUlELg0KCT4NCgk+IFRoZSBjdXJyZW50IGRyYWZ0IHJlYWRzIHRv IG1lIHRoYXQgdGhlIFRSLUlEIHNob3VsZCBiZSB1bmlxdWUgd2l0aGluIGENCgk+IHNlc3Npb24s IGJ1dCB0aGVyZSBzdGlsbCBpc24ndCBhbnkgZHVwbGljYXRlIHN1cHByZXNzaW9uIG9uIHRoZQ0K CT4gcmVjaXBpZW50IHNpZGUuIElmIHRoaXMgaXMgdGhlIGNhc2UsIEkgZG9uJ3QgZXZlbiBzZWUg d2h5IFRSLUlEIG5lZWRzIHRvDQoJPiBiZSB1bmlxdWUgd2l0aGluIGEgc2Vzc2lvbi4gSXQgd291 bGQgc2VlbSBlbm91Z2ggZm9yIHRoZSBzZW5kZXIgbm90IHRvDQoJPiBoYXZlIFRSLUlEIGNvbGxp c2lvbnMgb2NjdXIgd2l0aGluIHRoZSBzZXQgb2YgKnBlbmRpbmcqIHJlcXVlc3RzLiBpbg0KCT4g b3RoZXIgd29yZHMsIHRoZSBUUi1JRCBpcyBvcGFxdWUgdG8gdGhlIHJlY2lwaWVudCAtIHdoYXRl dmVyIHRoZSByZXF1ZXN0DQoJPiBoYWQgaXMgdXNlZCBpbiB0aGUgcmVzcG9uc2UuDQoJDQoJVGhl IHJlYWwgcmVxdWlyZW1lbnQgZm9yIHRoZSBjdXJyZW50IHVzYWdlIGlzIGV4YWN0bHkgYXMgeW91 IHNheSwgdGhhdA0KCWlzLCBubyBjb2xsaXNpb25zIHdpdGhpbiB0aGUgc2V0IG9mIHBlbmRpbmcg cmVxdWVzdHMuIE1ha2luZyB0aGVtIHVuaXF1ZQ0KCWluc2lkZSBhIHNlc3Npb24gc2ltcGx5IHNl ZW1lZCB0aGUgZWFzaWVzdCB3YXkgdG8gZW5mb3JjZSB0aGlzLg0KCQ0KCT4NCgk+IEhhdmluZyBz YWlkIHRoYXQsIEkgdGhpbmsgVFItSUQgaXMgbm90IHdvcmtpbmcgdG8gaXRzIGZ1bGwgcG90ZW50 aWFsLA0KCT4gYW5kIHRodXMgSSBoYXZlIGEgbmV3IHByb3Bvc2FsLg0KCT4NCgk+IExldCdzIG1h a2UgVFItSUQgYSBzaW1wbGUgY291bnRlci4gRWFjaCBzZXNzaW9uIHN0YXJ0cyBmcm9tIHplcm8s IGFuZA0KCT4gZWFjaCBuZXcgbWVzc2FnZSBpbmNyZW1lbnRzIHRoaXMgY291bnRlci4gV2UgY2Fu IGNvbWUgdXAgd2l0aCBhDQoJPiByZWFzb25hYmxlIHJlc29sdXRpb24gZm9yIHRoaXMgY291bnRl cjsgeCBzZWVtcyBhcyBnb29kIGEgdmFsdWUgYXMgYW55Lg0KCT4gV2hlbiB0aGUgY291bnRlciBo aXRzIHgsIGl0IGlzIHJlc2V0IHRvIHplcm8uDQoJPiBUaGUgZ29vZCB0aGluZyBpcyB0aGF0IHdl IGdldCBkdXBsaWNhdGUgZGV0ZWN0aW9uIHdpdGhvdXQgdGhlIHJlY2lwaWVudA0KCT4gaGF2aW5n IHRvIHJlbWVtYmVyIGFsbCB1c2VkIFRSLUlEcyB3aXRoaW4gYSBzZXNzaW9uLCBidXQgaXQgc3Vm ZmljZXMgdG8NCgk+IG1haW50YWluIHRoaXMgdW5pZGlyZWN0aW9uYWwgY291bnRlciBvbiBlYWNo IGVuZC4NCgk+DQoJPiBXaGF0ZXZlciB0aGUgcmVzb2x1dGlvbiB3aWxsIGJlLCBpdCBzZWVtcyBh IHJlYXNvbmFibGUgbGltaXRhdGlvbiB0byBzYXkNCgk+IHRoYXQgYSBzZW5kZXIgY2FuIG9ubHkg aGF2ZSB4IHBlbmRpbmcgcmVxdWVzdHMgYXQgYSB0aW1lLg0KCQ0KCVRoaXMgaXMgaW50ZXJlc3Rp bmcuIFdlIG9yaWdpbmFsbHkgYXZvaWRlZCB0aGlzIGFwcHJvYWNoIGR1ZSB0bw0KCXBvdGVudGlh bCBwcm9ibGVtcyB3aXRoIHNoYXJlZCBjb25uZWN0aW9ucywgZXRjLiBUaGVzZSBwcm9ibGVtcyBt YXkgYWxsDQoJYmUgZ29uZSB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24uIE9uZSBwb3RlbnRpYWwg cHJvYmxlbSBjb21lcyB0byBtaW5kDQoJaXMsIGlmIFRSLUlEIDIgdGltZXMgb3V0IF9hbmRfIHdh cyBuZXZlciBwcmVzZW50ZWQgdG8gdGhlIHJlY2lwaWVudCwNCglUUi1JRCAzIGlzIGRlbGl2ZXJl ZCwgdGhlbiBUUi1JRCAyIGlzIHJlc3VibWl0dGVkLCBpdCBtYXkgZmFsc2VseSBiZQ0KCXRyZWF0 ZWQgYXMgYSBkdXBsaWNhdGUuIE5vdywgSSBhbSBub3Qgc3VyZSB0aGlzIGNhbiByZWFsbHkgaGFw cGVuDQoJYXNzdW1pbmcgVENQIGNvbm5lY3Rpb25zIGFsbCB0aGUgd2F5LiBJZiB0aGUgcmVjZWl2 aW5nIHBlZXIgaXMNCglvdmVybG9hZGVkLCBidXQgcmVjb3ZlcnMgd2VsbCBlbm91Z2ggdG8gcHJv Y2VzcyBUUi1JRCAzLCB0aGVuIFRSLUlEIDINCgl3aWxsIG1vc3QgbGlrZWx5IGdldCBwcm9jZXNz ZWQgZmlyc3QgYW55d2F5LCB3b3VsZG4ndCBpdD8NCgkNCgkgIERvZXMgYW55b25lIHJlY2FsbCBh IHByb2JsZW0gd2l0aCByZXF1aXJpbmcgb3JkZXJlZCwgY29udGlndW91cyBUUi1JRA0KCXZhbHVl cywgYW5kIGFsbG93aW5nIHRoZSByZWNlaXZpbmcgcGVlciB0byBub3RpY2UgZGlzY3JlcGFuY2ll cywgdGhhdCBpcw0KCXN0aWxsIHJlbGV2YW50Pw0KCQ0KDQoJDQoJDQoJPg0KCT4gQ2hlZXJzLA0K CT4gQWtpDQoJPg0KCT4gZXh0IEJlbiBDYW1wYmVsbCB3cm90ZToNCgk+DQoJPj4gUGF1bCBLeXpp dmF0IHdyb3RlOg0KCT4+DQoJPj4gWy4uLl0NCgk+Pg0KCT4+Pg0KCT4+PiBJJ20gbm90IGNlcnRh aW4gYSB0aW1lIHBlcmlvZCBpcyByZWFsbHkgbmVjZXNzYXJ5LiBJIHRoaW5rIHRoaXMgY2FuDQoJ Pj4+IGJlIGxvY2FsIG9wdGlvbi4NCgk+Pj4NCgk+Pj4gRXZlbiB1bmlxdWVuZXNzIGFjcm9zcyBz dHJlYW1zIGlzbid0ICpyZXF1aXJlZCosIHRob3VnaCBpdCB3b3VsZCBiZQ0KCT4+PiBoZWxwZnVs LiBJbnN0ZWFkLCB3ZSBjYW4gc2ltcGx5IGludHJvZHVjZSBhbiBlcnJvciByZXNwb25zZSB0byBi ZQ0KCT4+PiB1c2VkIHdoZW4gYSBkdXBsaWNhdGUgaXMgZGV0ZWN0ZWQgYW5kIHN1cHJlc3NlZC4g SWYgaXQgd2FzIHN1cHJlc3NlZA0KCT4+PiBpbiBlcnJvciBiZWNhdXNlIHRoZSBzZW5kZXIgZHVw bGljYXRlZCBhIFRSLUlEIGZyb20gYW5vdGhlciBzdHJlYW0sDQoJPj4+IHRoZSBzZW5kZXIgd291 bGQgdGhlbiBrbm93IHRvIHJlY292ZXIuDQoJPj4+DQoJPj4+IEJ1dCBJIGFncmVlIHRoYXQgc29t ZSBmdXJ0aGVyIGNsYXJpZmljYXRpb24gb24gVFItSUQgdW5pcXVlbmVzcyBjb3VsZA0KCT4+PiBi ZSBoZWxwZnVsLg0KCT4+Pg0KCT4+DQoJPj4gSWYgVFItSUQgaXMgbm90IHJlcXVpcmVkIHRvIGJl IHVuaXF1ZSBhY3Jvc3Mgc2Vzc2lvbnMsIGFuZCB5b3UgYWxsb3cNCgk+PiBjbGllbnRzIHRvIGF0 dGVtcHQgdG8gZmluZCBkdXBsaWNhdGUgbWVzc2FnZXMgdXNpbmcgVFItSUQgYWNyb3NzDQoJPj4g c2Vzc2lvbnMsIHRoZW4geW91IGludHJvZHVjZSB0aGUgcG9zc2liaWxpdHkgb2YgZmFsc2UgZGV0 ZWN0aW9uIGNhdXNlZA0KCT4+IGJ5IFRSLUlEIGNvbGxpc2lvbnMuIFRoaXMgc2VlbXMgYmFkIHRv IG1lLg0KCT4+DQoJPj4NCgk+Pg0KCT4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoJPj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KCT4+IFNpbXBsZUBpZXRm Lm9yZw0KCT4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0K CQ0KCQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoJU2ltcGxlIG1haWxpbmcgbGlzdA0KCVNpbXBsZUBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KCQ0KDQo= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 17:36:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18147 for ; Mon, 10 Nov 2003 17:36:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKdi-0002OY-11 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMa55B009200 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKdh-0002OJ-A3 for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18068; Mon, 10 Nov 2003 17:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKdd-0006KM-00; Mon, 10 Nov 2003 17:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKdd-0006KJ-00; Mon, 10 Nov 2003 17:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKdd-0002MP-AL; Mon, 10 Nov 2003 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKdV-0002Lm-3D for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:35:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18059 for ; Mon, 10 Nov 2003 17:35:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKdS-0006K4-00 for simple@ietf.org; Mon, 10 Nov 2003 17:35:50 -0500 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AJKdR-0006Jz-00 for simple@ietf.org; Mon, 10 Nov 2003 17:35:50 -0500 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Mon, 10 Nov 2003 22:38:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Simple] Comments on message-sessions-02 - message retry Message-ID: <45730E094814E44488F789C1CDED27AE0219B103@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOn1Xa/+D+cc2qFTlq8ejhsB+wt6AABLt9H From: "Chris Boulton" To: "Ben Campbell" , "Aki Niemi" Cc: "Paul Kyzivat" , , Content-Transfer-Encoding: base64 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 22:35:47 -0000 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhpcyBkb2VzIHNlZW0gbGlrZSBhIGNsZWFuZXIgc29sdXRpb24uICBJIHBlcnNvbmFsbHkgZG9u J3Qgc2VlIGFueSBwcm9ibGVtcyB1c2luZyB0aGlzIGFwcHJvYWNoIC4NCiANCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIA0KRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQGR5 bmFtaWNzb2Z0LmNvbV0gDQpTZW50OiBNb24gMTAvMTEvMjAwMyAyMTo1NSANClRvOiBBa2kgTmll bWkgDQpDYzogUGF1bCBLeXppdmF0OyBoaXNoYW0ua2hhcnRhYmlsQG5va2lhLmNvbTsgc2ltcGxl QGlldGYub3JnIA0KU3ViamVjdDogUmU6IFtTaW1wbGVdIENvbW1lbnRzIG9uIG1lc3NhZ2Utc2Vz c2lvbnMtMDIgLSBtZXNzYWdlIHJldHJ5DQoNCg0KDQoJQWtpIE5pZW1pIHdyb3RlOg0KCQ0KCT4g SGksDQoJPg0KCT4gQXQgdGhpcyBwb2ludCBJJ20gcmVhbGx5IGNvbmZ1c2VkIGFib3V0IHRoZSB0 cnVlIG1lYW5pbmcgZm9yIFRSLUlELg0KCT4NCgk+IFRoZSBjdXJyZW50IGRyYWZ0IHJlYWRzIHRv IG1lIHRoYXQgdGhlIFRSLUlEIHNob3VsZCBiZSB1bmlxdWUgd2l0aGluIGENCgk+IHNlc3Npb24s IGJ1dCB0aGVyZSBzdGlsbCBpc24ndCBhbnkgZHVwbGljYXRlIHN1cHByZXNzaW9uIG9uIHRoZQ0K CT4gcmVjaXBpZW50IHNpZGUuIElmIHRoaXMgaXMgdGhlIGNhc2UsIEkgZG9uJ3QgZXZlbiBzZWUg d2h5IFRSLUlEIG5lZWRzIHRvDQoJPiBiZSB1bmlxdWUgd2l0aGluIGEgc2Vzc2lvbi4gSXQgd291 bGQgc2VlbSBlbm91Z2ggZm9yIHRoZSBzZW5kZXIgbm90IHRvDQoJPiBoYXZlIFRSLUlEIGNvbGxp c2lvbnMgb2NjdXIgd2l0aGluIHRoZSBzZXQgb2YgKnBlbmRpbmcqIHJlcXVlc3RzLiBpbg0KCT4g b3RoZXIgd29yZHMsIHRoZSBUUi1JRCBpcyBvcGFxdWUgdG8gdGhlIHJlY2lwaWVudCAtIHdoYXRl dmVyIHRoZSByZXF1ZXN0DQoJPiBoYWQgaXMgdXNlZCBpbiB0aGUgcmVzcG9uc2UuDQoJDQoJVGhl IHJlYWwgcmVxdWlyZW1lbnQgZm9yIHRoZSBjdXJyZW50IHVzYWdlIGlzIGV4YWN0bHkgYXMgeW91 IHNheSwgdGhhdA0KCWlzLCBubyBjb2xsaXNpb25zIHdpdGhpbiB0aGUgc2V0IG9mIHBlbmRpbmcg cmVxdWVzdHMuIE1ha2luZyB0aGVtIHVuaXF1ZQ0KCWluc2lkZSBhIHNlc3Npb24gc2ltcGx5IHNl ZW1lZCB0aGUgZWFzaWVzdCB3YXkgdG8gZW5mb3JjZSB0aGlzLg0KCQ0KCT4NCgk+IEhhdmluZyBz YWlkIHRoYXQsIEkgdGhpbmsgVFItSUQgaXMgbm90IHdvcmtpbmcgdG8gaXRzIGZ1bGwgcG90ZW50 aWFsLA0KCT4gYW5kIHRodXMgSSBoYXZlIGEgbmV3IHByb3Bvc2FsLg0KCT4NCgk+IExldCdzIG1h a2UgVFItSUQgYSBzaW1wbGUgY291bnRlci4gRWFjaCBzZXNzaW9uIHN0YXJ0cyBmcm9tIHplcm8s IGFuZA0KCT4gZWFjaCBuZXcgbWVzc2FnZSBpbmNyZW1lbnRzIHRoaXMgY291bnRlci4gV2UgY2Fu IGNvbWUgdXAgd2l0aCBhDQoJPiByZWFzb25hYmxlIHJlc29sdXRpb24gZm9yIHRoaXMgY291bnRl cjsgeCBzZWVtcyBhcyBnb29kIGEgdmFsdWUgYXMgYW55Lg0KCT4gV2hlbiB0aGUgY291bnRlciBo aXRzIHgsIGl0IGlzIHJlc2V0IHRvIHplcm8uDQoJPiBUaGUgZ29vZCB0aGluZyBpcyB0aGF0IHdl IGdldCBkdXBsaWNhdGUgZGV0ZWN0aW9uIHdpdGhvdXQgdGhlIHJlY2lwaWVudA0KCT4gaGF2aW5n IHRvIHJlbWVtYmVyIGFsbCB1c2VkIFRSLUlEcyB3aXRoaW4gYSBzZXNzaW9uLCBidXQgaXQgc3Vm ZmljZXMgdG8NCgk+IG1haW50YWluIHRoaXMgdW5pZGlyZWN0aW9uYWwgY291bnRlciBvbiBlYWNo IGVuZC4NCgk+DQoJPiBXaGF0ZXZlciB0aGUgcmVzb2x1dGlvbiB3aWxsIGJlLCBpdCBzZWVtcyBh IHJlYXNvbmFibGUgbGltaXRhdGlvbiB0byBzYXkNCgk+IHRoYXQgYSBzZW5kZXIgY2FuIG9ubHkg aGF2ZSB4IHBlbmRpbmcgcmVxdWVzdHMgYXQgYSB0aW1lLg0KCQ0KCVRoaXMgaXMgaW50ZXJlc3Rp bmcuIFdlIG9yaWdpbmFsbHkgYXZvaWRlZCB0aGlzIGFwcHJvYWNoIGR1ZSB0bw0KCXBvdGVudGlh bCBwcm9ibGVtcyB3aXRoIHNoYXJlZCBjb25uZWN0aW9ucywgZXRjLiBUaGVzZSBwcm9ibGVtcyBt YXkgYWxsDQoJYmUgZ29uZSB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24uIE9uZSBwb3RlbnRpYWwg cHJvYmxlbSBjb21lcyB0byBtaW5kDQoJaXMsIGlmIFRSLUlEIDIgdGltZXMgb3V0IF9hbmRfIHdh cyBuZXZlciBwcmVzZW50ZWQgdG8gdGhlIHJlY2lwaWVudCwNCglUUi1JRCAzIGlzIGRlbGl2ZXJl ZCwgdGhlbiBUUi1JRCAyIGlzIHJlc3VibWl0dGVkLCBpdCBtYXkgZmFsc2VseSBiZQ0KCXRyZWF0 ZWQgYXMgYSBkdXBsaWNhdGUuIE5vdywgSSBhbSBub3Qgc3VyZSB0aGlzIGNhbiByZWFsbHkgaGFw cGVuDQoJYXNzdW1pbmcgVENQIGNvbm5lY3Rpb25zIGFsbCB0aGUgd2F5LiBJZiB0aGUgcmVjZWl2 aW5nIHBlZXIgaXMNCglvdmVybG9hZGVkLCBidXQgcmVjb3ZlcnMgd2VsbCBlbm91Z2ggdG8gcHJv Y2VzcyBUUi1JRCAzLCB0aGVuIFRSLUlEIDINCgl3aWxsIG1vc3QgbGlrZWx5IGdldCBwcm9jZXNz ZWQgZmlyc3QgYW55d2F5LCB3b3VsZG4ndCBpdD8NCgkNCgkgIERvZXMgYW55b25lIHJlY2FsbCBh IHByb2JsZW0gd2l0aCByZXF1aXJpbmcgb3JkZXJlZCwgY29udGlndW91cyBUUi1JRA0KCXZhbHVl cywgYW5kIGFsbG93aW5nIHRoZSByZWNlaXZpbmcgcGVlciB0byBub3RpY2UgZGlzY3JlcGFuY2ll cywgdGhhdCBpcw0KCXN0aWxsIHJlbGV2YW50Pw0KCQ0KDQoJDQoJDQoJPg0KCT4gQ2hlZXJzLA0K CT4gQWtpDQoJPg0KCT4gZXh0IEJlbiBDYW1wYmVsbCB3cm90ZToNCgk+DQoJPj4gUGF1bCBLeXpp dmF0IHdyb3RlOg0KCT4+DQoJPj4gWy4uLl0NCgk+Pg0KCT4+Pg0KCT4+PiBJJ20gbm90IGNlcnRh aW4gYSB0aW1lIHBlcmlvZCBpcyByZWFsbHkgbmVjZXNzYXJ5LiBJIHRoaW5rIHRoaXMgY2FuDQoJ Pj4+IGJlIGxvY2FsIG9wdGlvbi4NCgk+Pj4NCgk+Pj4gRXZlbiB1bmlxdWVuZXNzIGFjcm9zcyBz dHJlYW1zIGlzbid0ICpyZXF1aXJlZCosIHRob3VnaCBpdCB3b3VsZCBiZQ0KCT4+PiBoZWxwZnVs LiBJbnN0ZWFkLCB3ZSBjYW4gc2ltcGx5IGludHJvZHVjZSBhbiBlcnJvciByZXNwb25zZSB0byBi ZQ0KCT4+PiB1c2VkIHdoZW4gYSBkdXBsaWNhdGUgaXMgZGV0ZWN0ZWQgYW5kIHN1cHJlc3NlZC4g SWYgaXQgd2FzIHN1cHJlc3NlZA0KCT4+PiBpbiBlcnJvciBiZWNhdXNlIHRoZSBzZW5kZXIgZHVw bGljYXRlZCBhIFRSLUlEIGZyb20gYW5vdGhlciBzdHJlYW0sDQoJPj4+IHRoZSBzZW5kZXIgd291 bGQgdGhlbiBrbm93IHRvIHJlY292ZXIuDQoJPj4+DQoJPj4+IEJ1dCBJIGFncmVlIHRoYXQgc29t ZSBmdXJ0aGVyIGNsYXJpZmljYXRpb24gb24gVFItSUQgdW5pcXVlbmVzcyBjb3VsZA0KCT4+PiBi ZSBoZWxwZnVsLg0KCT4+Pg0KCT4+DQoJPj4gSWYgVFItSUQgaXMgbm90IHJlcXVpcmVkIHRvIGJl IHVuaXF1ZSBhY3Jvc3Mgc2Vzc2lvbnMsIGFuZCB5b3UgYWxsb3cNCgk+PiBjbGllbnRzIHRvIGF0 dGVtcHQgdG8gZmluZCBkdXBsaWNhdGUgbWVzc2FnZXMgdXNpbmcgVFItSUQgYWNyb3NzDQoJPj4g c2Vzc2lvbnMsIHRoZW4geW91IGludHJvZHVjZSB0aGUgcG9zc2liaWxpdHkgb2YgZmFsc2UgZGV0 ZWN0aW9uIGNhdXNlZA0KCT4+IGJ5IFRSLUlEIGNvbGxpc2lvbnMuIFRoaXMgc2VlbXMgYmFkIHRv IG1lLg0KCT4+DQoJPj4NCgk+Pg0KCT4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoJPj4gU2ltcGxlIG1haWxpbmcgbGlzdA0KCT4+IFNpbXBsZUBpZXRm Lm9yZw0KCT4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0K CQ0KCQ0KCQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoJU2ltcGxlIG1haWxpbmcgbGlzdA0KCVNpbXBsZUBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZQ0KCQ0KDQo= _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 17:42:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18533; Mon, 10 Nov 2003 17:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKkO-0006Re-00; Mon, 10 Nov 2003 17:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKkN-0006RZ-00; Mon, 10 Nov 2003 17:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKkO-0003A9-Ey; Mon, 10 Nov 2003 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKjY-00038b-GW for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:42:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18461 for ; Mon, 10 Nov 2003 17:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKjV-0006PN-00 for simple@ietf.org; Mon, 10 Nov 2003 17:42:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJKjV-0006ON-00 for simple@ietf.org; Mon, 10 Nov 2003 17:42:05 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 14:44:53 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAAMfWiN012634; Mon, 10 Nov 2003 14:41:32 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW51244; Mon, 10 Nov 2003 17:41:31 -0500 (EST) Message-ID: <3FB0141B.4050802@cisco.com> 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: Ben Campbell CC: Adam Roach , Jonathan Rosenberg , Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> <3FB0108A.1000806@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 17:41:31 -0500 Content-Transfer-Encoding: 7bit I agree Adam's suggestion is somewhat attractive. OTOH, while my initial reaction to Jonathan's #3 was "that's bonkers", it has started to grow on me. It has the advantage that the UAC doesn't need to know what server will process the request. It is a potential problem if the first hop proxy doesn't know how to route it, but that is a solvable problem - a Route header in the request to send it somewhere that does. Paul Ben Campbell wrote: > I like this approach alot. > > Adam Roach wrote: > >> Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: >> >> >>> (3) its a CID URI, referring to the list in the body of the request >> >> >> >> That has the potential to make routing very difficult. If the first proxy >> that you hit doesn't know what the cid scheme means, then things won't >> work. >> It seems to me that the most flexible approach would be something like: >> >> SUBSCRIBE sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com >> SIP/2.0 >> >> Nice thing about this is that you could also do something like: >> >> SUBSCRIBE >> sip:group@example.com;list=http://xcap.example.com/services/presence-lists/u >> >> sers/bill/fr.xml SIP/2.0 >> >> /a >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 17:43:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18570 for ; Mon, 10 Nov 2003 17:43:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKkR-0003BG-UR for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMh3uI012220 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKkR-0003B1-Qv for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:43:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18533; Mon, 10 Nov 2003 17:42:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKkO-0006Re-00; Mon, 10 Nov 2003 17:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKkN-0006RZ-00; Mon, 10 Nov 2003 17:42:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKkO-0003A9-Ey; Mon, 10 Nov 2003 17:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKjY-00038b-GW for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:42:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18461 for ; Mon, 10 Nov 2003 17:41:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKjV-0006PN-00 for simple@ietf.org; Mon, 10 Nov 2003 17:42:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJKjV-0006ON-00 for simple@ietf.org; Mon, 10 Nov 2003 17:42:05 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2003 14:44:53 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAAMfWiN012634; Mon, 10 Nov 2003 14:41:32 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-107.cisco.com [10.86.240.107]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW51244; Mon, 10 Nov 2003 17:41:31 -0500 (EST) Message-ID: <3FB0141B.4050802@cisco.com> 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: Ben Campbell CC: Adam Roach , Jonathan Rosenberg , Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865DF@dyn-tx-exch-001.dynamicsoft.com> <3FB0108A.1000806@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 17:41:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree Adam's suggestion is somewhat attractive. OTOH, while my initial reaction to Jonathan's #3 was "that's bonkers", it has started to grow on me. It has the advantage that the UAC doesn't need to know what server will process the request. It is a potential problem if the first hop proxy doesn't know how to route it, but that is a solvable problem - a Route header in the request to send it somewhere that does. Paul Ben Campbell wrote: > I like this approach alot. > > Adam Roach wrote: > >> Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: >> >> >>> (3) its a CID URI, referring to the list in the body of the request >> >> >> >> That has the potential to make routing very difficult. If the first proxy >> that you hit doesn't know what the cid scheme means, then things won't >> work. >> It seems to me that the most flexible approach would be something like: >> >> SUBSCRIBE sip:group@example.com;list=cid:cn35t8jf02@terminal.foo.com >> SIP/2.0 >> >> Nice thing about this is that you could also do something like: >> >> SUBSCRIBE >> sip:group@example.com;list=http://xcap.example.com/services/presence-lists/u >> >> sers/bill/fr.xml SIP/2.0 >> >> /a >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 17:55:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19061; Mon, 10 Nov 2003 17:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKx3-0006fg-00; Mon, 10 Nov 2003 17:56:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKx3-0006fd-00; Mon, 10 Nov 2003 17:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKx2-0003hL-87; Mon, 10 Nov 2003 17:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKw1-0003et-My for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:55:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19035 for ; Mon, 10 Nov 2003 17:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKvy-0006eP-00 for simple@ietf.org; Mon, 10 Nov 2003 17:54:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJKvy-0006df-00 for simple@ietf.org; Mon, 10 Nov 2003 17:54:58 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 15:00:46 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAMsQAt004061; Mon, 10 Nov 2003 14:54:27 -0800 (PST) Received: from [130.129.142.157] (sjc-vpn4-478.cisco.com [10.21.81.222]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV16774; Mon, 10 Nov 2003 14:54:25 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP Comments From: Cullen Jennings To: Ben Campbell CC: Message-ID: In-Reply-To: <3FAFB649.3000505@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 12:19:33 -0800 Content-Transfer-Encoding: 7bit Inline ... I have tried to explain this better at the bottom ... On 11/10/03 8:01 AM, "Ben Campbell" wrote: > Cullen Jennings wrote: > >> >> The draft does not say much about if the forming a separate TCP connection >> for each session between two relays. > > I suspect there is a typo in this sentence: Is the "if" spurious, or is > something else missing? (Really, I am not trying to pick at typos--I am > just not sure of the meaning.) > Very sorry - yes, I did not mean to put the "if" >> Some people have said this will use >> less bandwidth than a single connection. I think it will consume much more. > > I was not aware anyone thought using a connection per session would > require less bandwidth than shared connections. The arguments against > shared sessions were based on protocol complexity and head-of-line > blocking issues. > I phrased this very poorly - I was not actually worried about the issue where slightly more bits are transported when using two streams than one. My concern was around the congestion control properties of N parallel TCP streams VS 1. Particularly what percentage of the total available bandwidth this 1 or N streams will get, and what percentage it deservers. >> The question is if this is trashing the commons or not - I don't know. >> Given one of the major reasons for not just using Page mode for everything >> revolves around concession control, I think it needs a little discussion. >> Not that we are doing this but ... Setting up a new TCP connection for every >> UDP packet you want to send completely defeats the congestion control >> properties of TCP. > > Do you mean more discussion in the document, or in the work group? We > have discussed this a lot in the group, and I have not heard a new > argument in a while now... > The last email I seem to have on it has Dean presenting a reasonable argument that the effect will be X and Jonathan presenting a reasonable argument the the effect will be not X. See www1.ietf.org/mail-archive/working-groups/simple/current/msg01316.html I don't think this ever got resolved. Let's go with the following assumptions which may or may not be relevant. There are two relays that have 100k sessions between them. Each session sends an 1k IM message every 10 seconds. The link is horribly congested and has a 10% packet loss. Imagine there is also a bunch of SMTP traffic over the same link. What will happen in both the 1 stream and 100k stream case? How does the relative percentage of IM to SMTP compare in both cases? How does the 100k stream case compare to if the packets had been sent over UDP? Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 17:56:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19097 for ; Mon, 10 Nov 2003 17:56:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKx7-0003jK-Su for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:56:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAMu9DZ014338 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 17:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKx7-0003jB-Jl for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 17:56:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19061; Mon, 10 Nov 2003 17:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKx3-0006fg-00; Mon, 10 Nov 2003 17:56:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJKx3-0006fd-00; Mon, 10 Nov 2003 17:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKx2-0003hL-87; Mon, 10 Nov 2003 17:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJKw1-0003et-My for simple@optimus.ietf.org; Mon, 10 Nov 2003 17:55:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19035 for ; Mon, 10 Nov 2003 17:54:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJKvy-0006eP-00 for simple@ietf.org; Mon, 10 Nov 2003 17:54:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJKvy-0006df-00 for simple@ietf.org; Mon, 10 Nov 2003 17:54:58 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 15:00:46 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAAMsQAt004061; Mon, 10 Nov 2003 14:54:27 -0800 (PST) Received: from [130.129.142.157] (sjc-vpn4-478.cisco.com [10.21.81.222]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV16774; Mon, 10 Nov 2003 14:54:25 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP Comments From: Cullen Jennings To: Ben Campbell CC: Message-ID: In-Reply-To: <3FAFB649.3000505@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 12:19:33 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline ... I have tried to explain this better at the bottom ... On 11/10/03 8:01 AM, "Ben Campbell" wrote: > Cullen Jennings wrote: > >> >> The draft does not say much about if the forming a separate TCP connection >> for each session between two relays. > > I suspect there is a typo in this sentence: Is the "if" spurious, or is > something else missing? (Really, I am not trying to pick at typos--I am > just not sure of the meaning.) > Very sorry - yes, I did not mean to put the "if" >> Some people have said this will use >> less bandwidth than a single connection. I think it will consume much more. > > I was not aware anyone thought using a connection per session would > require less bandwidth than shared connections. The arguments against > shared sessions were based on protocol complexity and head-of-line > blocking issues. > I phrased this very poorly - I was not actually worried about the issue where slightly more bits are transported when using two streams than one. My concern was around the congestion control properties of N parallel TCP streams VS 1. Particularly what percentage of the total available bandwidth this 1 or N streams will get, and what percentage it deservers. >> The question is if this is trashing the commons or not - I don't know. >> Given one of the major reasons for not just using Page mode for everything >> revolves around concession control, I think it needs a little discussion. >> Not that we are doing this but ... Setting up a new TCP connection for every >> UDP packet you want to send completely defeats the congestion control >> properties of TCP. > > Do you mean more discussion in the document, or in the work group? We > have discussed this a lot in the group, and I have not heard a new > argument in a while now... > The last email I seem to have on it has Dean presenting a reasonable argument that the effect will be X and Jonathan presenting a reasonable argument the the effect will be not X. See www1.ietf.org/mail-archive/working-groups/simple/current/msg01316.html I don't think this ever got resolved. Let's go with the following assumptions which may or may not be relevant. There are two relays that have 100k sessions between them. Each session sends an 1k IM message every 10 seconds. The link is horribly congested and has a 10% packet loss. Imagine there is also a bunch of SMTP traffic over the same link. What will happen in both the 1 stream and 100k stream case? How does the relative percentage of IM to SMTP compare in both cases? How does the 100k stream case compare to if the packets had been sent over UDP? Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 18:26:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22120; Mon, 10 Nov 2003 18:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLR3-0007JE-00; Mon, 10 Nov 2003 18:27:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJLR3-0007JB-00; Mon, 10 Nov 2003 18:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLQy-0005d0-Hz; Mon, 10 Nov 2003 18:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLQF-0005cI-Nm for simple@optimus.ietf.org; Mon, 10 Nov 2003 18:26:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22074 for ; Mon, 10 Nov 2003 18:26:00 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLQC-0007IG-00 for simple@ietf.org; Mon, 10 Nov 2003 18:26:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJLQB-0007ID-00 for simple@ietf.org; Mon, 10 Nov 2003 18:26:11 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAANQBc06016 for ; Tue, 11 Nov 2003 01:26:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 01:26:11 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 01:26:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOn2ewOW53cUVtEQ5SC8a5dIGSaGgABurpg To: , Cc: , X-OriginalArrivalTime: 10 Nov 2003 23:26:10.0425 (UTC) FILETIME=[06282E90:01C3A7E2] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 01:26:09 +0200 Content-Transfer-Encoding: quoted-printable Again I ask: why is there a need for retransmission? As I said earlier, = if a message fails (timeout or 5xx), the end user gets presented with = this error and it is up to him/her to send it again. If it was a long message and a timeout has occurred, then only the user = can decide to send it again (again I'm pointing out that long messages = can wrongly time out) /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, November 11, 2003 12:27 AM > To: Ben Campbell > Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); > simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > Its true that within a given session it should be sufficient to=20 > distinguish between the currently pending messages. So TR-IDs for=20 > acknowledged messages could be recycled. >=20 > OTOH, without some tweaks that makes the problem of failing over to=20 > another session harder. >=20 > This could perhaps be handled by making a two-part TR-ID:=20 > .. So when a session is established for the=20 > first time,=20 > ids are of the form 1.1, 1.2, ... Then, if it is necessary to=20 > fail over=20 > to a new session, then ids for new messages are 2.1, 2.2, ..., but=20 > retransmissions of old ones would still carry their original TR-ID. >=20 > A recipient that supports duplicate suppression would need to=20 > remember=20 > the ids of messages processed until certain the response had been=20 > received by the sender. This could be handled a number of=20 > different ways: > - reuse of a TR-ID in the *same* session isn't a retransmission. It > redefines what message it applies to. > - if a request is sent in the other direction, any responses sent > prior to it can be inferred to have been received, so the messages > corresponding to those responses will no longer be eligible for > retransmission. > - the timeout interval for messages puts an upper bound on how > long one needs to be prepared to deal with retransmissions of > a message. >=20 > Paul >=20 > Ben Campbell wrote: > > Aki Niemi wrote: > >=20 > >> Hi, > >> > >> At this point I'm really confused about the true meaning for TR-ID. > >> > >> The current draft reads to me that the TR-ID should be=20 > unique within a=20 > >> session, but there still isn't any duplicate suppression on the=20 > >> recipient side. If this is the case, I don't even see why=20 > TR-ID needs=20 > >> to be unique within a session. It would seem enough for=20 > the sender not=20 > >> to have TR-ID collisions occur within the set of *pending*=20 > requests.=20 > >> in other words, the TR-ID is opaque to the recipient -=20 > whatever the 5 > >> request had is used in the response. > >=20 > >=20 > > The real requirement for the current usage is exactly as=20 > you say, that=20 > > is, no collisions within the set of pending requests.=20 > Making them unique=20 > > inside a session simply seemed the easiest way to enforce this. > >=20 > >> > >> Having said that, I think TR-ID is not working to its full=20 > potential,=20 > >> and thus I have a new proposal. > >> > >> Let's make TR-ID a simple counter. Each session starts=20 > from zero, and=20 > >> each new message increments this counter. We can come up with a=20 > >> reasonable resolution for this counter; x seems as good a value as=20 > >> any. When the counter hits x, it is reset to zero. > >> The good thing is that we get duplicate detection without the=20 > >> recipient having to remember all used TR-IDs within a=20 > session, but it=20 > >> suffices to maintain this unidirectional counter on each end. > >> > >> Whatever the resolution will be, it seems a reasonable=20 > limitation to=20 > >> say that a sender can only have x pending requests at a time. > >=20 > >=20 > > This is interesting. We originally avoided this approach due to=20 > > potential problems with shared connections, etc. These=20 > problems may all=20 > > be gone with the current version. One potential problem=20 > comes to mind=20 > > is, if TR-ID 2 times out _and_ was never presented to the=20 > recipient,=20 > > TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may=20 > falsely be=20 > > treated as a duplicate. Now, I am not sure this can really happen=20 > > assuming TCP connections all the way. If the receiving peer is=20 > > overloaded, but recovers well enough to process TR-ID 3,=20 > then TR-ID 2=20 > > will most likely get processed first anyway, wouldn't it? > >=20 > > Does anyone recall a problem with requiring ordered,=20 > contiguous TR-ID=20 > > values, and allowing the receiving peer to notice=20 > discrepancies, that is=20 > > still relevant? > >=20 > >=20 > >> > >> Cheers, > >> Aki > >> > >> ext Ben Campbell wrote: > >> > >>> Paul Kyzivat wrote: > >>> > >>> [...] > >>> > >>>> > >>>> I'm not certain a time period is really necessary. I=20 > think this can=20 > >>>> be local option. > >>>> > >>>> Even uniqueness across streams isn't *required*, though=20 > it would be=20 > >>>> helpful. Instead, we can simply introduce an error=20 > response to be=20 > >>>> used when a duplicate is detected and supressed. If it=20 > was supressed=20 > >>>> in error because the sender duplicated a TR-ID from=20 > another stream,=20 > >>>> the sender would then know to recover. > >>>> > >>>> But I agree that some further clarification on TR-ID uniqueness=20 > >>>> could be helpful. > >>>> > >>> > >>> If TR-ID is not required to be unique across sessions,=20 > and you allow=20 > >>> clients to attempt to find duplicate messages using TR-ID across=20 > >>> sessions, then you introduce the possibility of false detection=20 > >>> caused by TR-ID collisions. This seems bad to me. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 18:27:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22162 for ; Mon, 10 Nov 2003 18:27:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLR8-0005gD-3e for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 18:27:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANRADw021832 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 18:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLR7-0005g3-Vt for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 18:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22120; Mon, 10 Nov 2003 18:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLR3-0007JE-00; Mon, 10 Nov 2003 18:27:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJLR3-0007JB-00; Mon, 10 Nov 2003 18:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLQy-0005d0-Hz; Mon, 10 Nov 2003 18:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLQF-0005cI-Nm for simple@optimus.ietf.org; Mon, 10 Nov 2003 18:26:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22074 for ; Mon, 10 Nov 2003 18:26:00 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLQC-0007IG-00 for simple@ietf.org; Mon, 10 Nov 2003 18:26:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJLQB-0007ID-00 for simple@ietf.org; Mon, 10 Nov 2003 18:26:11 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAANQBc06016 for ; Tue, 11 Nov 2003 01:26:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 01:26:11 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 01:26:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOn2ewOW53cUVtEQ5SC8a5dIGSaGgABurpg To: , Cc: , X-OriginalArrivalTime: 10 Nov 2003 23:26:10.0425 (UTC) FILETIME=[06282E90:01C3A7E2] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 01:26:09 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Again I ask: why is there a need for retransmission? As I said earlier, = if a message fails (timeout or 5xx), the end user gets presented with = this error and it is up to him/her to send it again. If it was a long message and a timeout has occurred, then only the user = can decide to send it again (again I'm pointing out that long messages = can wrongly time out) /Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, November 11, 2003 12:27 AM > To: Ben Campbell > Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); > simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > Its true that within a given session it should be sufficient to=20 > distinguish between the currently pending messages. So TR-IDs for=20 > acknowledged messages could be recycled. >=20 > OTOH, without some tweaks that makes the problem of failing over to=20 > another session harder. >=20 > This could perhaps be handled by making a two-part TR-ID:=20 > .. So when a session is established for the=20 > first time,=20 > ids are of the form 1.1, 1.2, ... Then, if it is necessary to=20 > fail over=20 > to a new session, then ids for new messages are 2.1, 2.2, ..., but=20 > retransmissions of old ones would still carry their original TR-ID. >=20 > A recipient that supports duplicate suppression would need to=20 > remember=20 > the ids of messages processed until certain the response had been=20 > received by the sender. This could be handled a number of=20 > different ways: > - reuse of a TR-ID in the *same* session isn't a retransmission. It > redefines what message it applies to. > - if a request is sent in the other direction, any responses sent > prior to it can be inferred to have been received, so the messages > corresponding to those responses will no longer be eligible for > retransmission. > - the timeout interval for messages puts an upper bound on how > long one needs to be prepared to deal with retransmissions of > a message. >=20 > Paul >=20 > Ben Campbell wrote: > > Aki Niemi wrote: > >=20 > >> Hi, > >> > >> At this point I'm really confused about the true meaning for TR-ID. > >> > >> The current draft reads to me that the TR-ID should be=20 > unique within a=20 > >> session, but there still isn't any duplicate suppression on the=20 > >> recipient side. If this is the case, I don't even see why=20 > TR-ID needs=20 > >> to be unique within a session. It would seem enough for=20 > the sender not=20 > >> to have TR-ID collisions occur within the set of *pending*=20 > requests.=20 > >> in other words, the TR-ID is opaque to the recipient -=20 > whatever the 5 > >> request had is used in the response. > >=20 > >=20 > > The real requirement for the current usage is exactly as=20 > you say, that=20 > > is, no collisions within the set of pending requests.=20 > Making them unique=20 > > inside a session simply seemed the easiest way to enforce this. > >=20 > >> > >> Having said that, I think TR-ID is not working to its full=20 > potential,=20 > >> and thus I have a new proposal. > >> > >> Let's make TR-ID a simple counter. Each session starts=20 > from zero, and=20 > >> each new message increments this counter. We can come up with a=20 > >> reasonable resolution for this counter; x seems as good a value as=20 > >> any. When the counter hits x, it is reset to zero. > >> The good thing is that we get duplicate detection without the=20 > >> recipient having to remember all used TR-IDs within a=20 > session, but it=20 > >> suffices to maintain this unidirectional counter on each end. > >> > >> Whatever the resolution will be, it seems a reasonable=20 > limitation to=20 > >> say that a sender can only have x pending requests at a time. > >=20 > >=20 > > This is interesting. We originally avoided this approach due to=20 > > potential problems with shared connections, etc. These=20 > problems may all=20 > > be gone with the current version. One potential problem=20 > comes to mind=20 > > is, if TR-ID 2 times out _and_ was never presented to the=20 > recipient,=20 > > TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may=20 > falsely be=20 > > treated as a duplicate. Now, I am not sure this can really happen=20 > > assuming TCP connections all the way. If the receiving peer is=20 > > overloaded, but recovers well enough to process TR-ID 3,=20 > then TR-ID 2=20 > > will most likely get processed first anyway, wouldn't it? > >=20 > > Does anyone recall a problem with requiring ordered,=20 > contiguous TR-ID=20 > > values, and allowing the receiving peer to notice=20 > discrepancies, that is=20 > > still relevant? > >=20 > >=20 > >> > >> Cheers, > >> Aki > >> > >> ext Ben Campbell wrote: > >> > >>> Paul Kyzivat wrote: > >>> > >>> [...] > >>> > >>>> > >>>> I'm not certain a time period is really necessary. I=20 > think this can=20 > >>>> be local option. > >>>> > >>>> Even uniqueness across streams isn't *required*, though=20 > it would be=20 > >>>> helpful. Instead, we can simply introduce an error=20 > response to be=20 > >>>> used when a duplicate is detected and supressed. If it=20 > was supressed=20 > >>>> in error because the sender duplicated a TR-ID from=20 > another stream,=20 > >>>> the sender would then know to recover. > >>>> > >>>> But I agree that some further clarification on TR-ID uniqueness=20 > >>>> could be helpful. > >>>> > >>> > >>> If TR-ID is not required to be unique across sessions,=20 > and you allow=20 > >>> clients to attempt to find duplicate messages using TR-ID across=20 > >>> sessions, then you introduce the possibility of false detection=20 > >>> caused by TR-ID collisions. This seems bad to me. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Simple mailing list > >>> Simple@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 20:55:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29139; Mon, 10 Nov 2003 20:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KE-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KA-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlA-0005RD-Np; Mon, 10 Nov 2003 20:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNkJ-0005Qf-05 for simple@optimus.ietf.org; Mon, 10 Nov 2003 20:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29110 for ; Mon, 10 Nov 2003 20:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNkG-0002JT-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:04 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJNkF-0002JQ-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:03 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAB1spIc082451; Mon, 10 Nov 2003 19:55:02 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAF0F47.2090301@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <3FAC1882.7070605@dynamicsoft.com> In-Reply-To: <3FAC1882.7070605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Nov 2003 22:08:39 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Orit, > > Some comments on: > http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-00.txt > > Generally, I do think we need something like this. It seems particularly > useful in environments where the list is not syncrhonized with the > network, but for which we want to get the benefits of list > subscriptions, in terms of reducing overhead. > > Firstly, this feels to me like it has a lot in common with the filter > work. Both this and the filter work use body objects to push policy > about the subscription to the server. Both have needs for updates to > these policy objects during the lifetime of the subscriptions. Both have > similar lifecycle managamenet requirements. Both provide details on > exactly what the subscription is for. Have you considered trying to > unify this with the filter work? Indeed, it might be useful to start off > with some requirements to define what we want to do here, we may not all > be on the same page. > > Secondly, one big question is - what is the request URI? I can see > several options: > > (1) its a well-known service URI, for example, sip:adhoclist@domain.com, > where the server knows that for any subscriptions to sip:adhoclist@ domain>, it means that the subscription has its contents in the body > > (2) its a SIP URI that doesnt match any existing resource in the domain. > Thus, the act of subscribing basically creates that resource as a list > resource > > (3) its a CID URI, referring to the list in the body of the request > > > I think you have (2) in mind. But, I'm not sure thats the right way to go. > > Thirdly, you talk about all subscribed parties to the list receiving a > notify when the list content changes: > >> When a resource is added to /deleted from the list, the RLS SHOULD >> generate a NOTIFY as if the list had been updated by any possible >> out-of-band means and in accordance with the notification mechanism >> and format established for this list. The updated information SHOULD >> be sent to all the parties being subscribed to this list (including >> the "list-owner"). > > > I dont get this. I thought that an ad-hoc list would be scoped to the > subscription, in which case, there wouldnt be any other subscribers. Am > I missing something? There are also some statements about uniquely naming the list, which only seem to make sense to me if the list is expected to be used outside of the dialog. > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 20:56:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29183 for ; Mon, 10 Nov 2003 20:56:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlI-0005XQ-5i for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 20:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB1u8PR021284 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 20:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlI-0005XC-0R for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 20:56:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29141; Mon, 10 Nov 2003 20:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KH-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KB-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlB-0005RV-Dd; Mon, 10 Nov 2003 20:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNkQ-0005Qm-Ll for simple@optimus.ietf.org; Mon, 10 Nov 2003 20:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29113 for ; Mon, 10 Nov 2003 20:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNkO-0002Jf-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:12 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJNkN-0002JW-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:11 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAB1t3Ic082480; Mon, 10 Nov 2003 19:55:04 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB04128.2020103@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 19:53:44 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In spite of the fact I keep letting myself get trapped into talking about retransmitting, I think I agree. If one attempt fails, it seems highly unlikely another attempt will suddenly succeed. hisham.khartabil@nokia.com wrote: > Again I ask: why is there a need for retransmission? As I said earlier, if a message fails (timeout or 5xx), the end user gets presented with this error and it is up to him/her to send it again. > > If it was a long message and a timeout has occurred, then only the user can decide to send it again (again I'm pointing out that long messages can wrongly time out) > > /Hisham > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, November 11, 2003 12:27 AM >>To: Ben Campbell >>Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 - message retry >> >> >>Its true that within a given session it should be sufficient to >>distinguish between the currently pending messages. So TR-IDs for >>acknowledged messages could be recycled. >> >>OTOH, without some tweaks that makes the problem of failing over to >>another session harder. >> >>This could perhaps be handled by making a two-part TR-ID: >>.. So when a session is established for the >>first time, >>ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>fail over >>to a new session, then ids for new messages are 2.1, 2.2, ..., but >>retransmissions of old ones would still carry their original TR-ID. >> >>A recipient that supports duplicate suppression would need to >>remember >>the ids of messages processed until certain the response had been >>received by the sender. This could be handled a number of >>different ways: >>- reuse of a TR-ID in the *same* session isn't a retransmission. It >> redefines what message it applies to. >>- if a request is sent in the other direction, any responses sent >> prior to it can be inferred to have been received, so the messages >> corresponding to those responses will no longer be eligible for >> retransmission. >>- the timeout interval for messages puts an upper bound on how >> long one needs to be prepared to deal with retransmissions of >> a message. >> >> Paul >> >>Ben Campbell wrote: >> >>>Aki Niemi wrote: >>> >>> >>>>Hi, >>>> >>>>At this point I'm really confused about the true meaning for TR-ID. >>>> >>>>The current draft reads to me that the TR-ID should be >> >>unique within a >> >>>>session, but there still isn't any duplicate suppression on the >>>>recipient side. If this is the case, I don't even see why >> >>TR-ID needs >> >>>>to be unique within a session. It would seem enough for >> >>the sender not >> >>>>to have TR-ID collisions occur within the set of *pending* >> >>requests. >> >>>>in other words, the TR-ID is opaque to the recipient - >> >>whatever the 5 >> >>>>request had is used in the response. >>> >>> >>>The real requirement for the current usage is exactly as >> >>you say, that >> >>>is, no collisions within the set of pending requests. >> >>Making them unique >> >>>inside a session simply seemed the easiest way to enforce this. >>> >>> >>>>Having said that, I think TR-ID is not working to its full >> >>potential, >> >>>>and thus I have a new proposal. >>>> >>>>Let's make TR-ID a simple counter. Each session starts >> >>from zero, and >> >>>>each new message increments this counter. We can come up with a >>>>reasonable resolution for this counter; x seems as good a value as >>>>any. When the counter hits x, it is reset to zero. >>>>The good thing is that we get duplicate detection without the >>>>recipient having to remember all used TR-IDs within a >> >>session, but it >> >>>>suffices to maintain this unidirectional counter on each end. >>>> >>>>Whatever the resolution will be, it seems a reasonable >> >>limitation to >> >>>>say that a sender can only have x pending requests at a time. >>> >>> >>>This is interesting. We originally avoided this approach due to >>>potential problems with shared connections, etc. These >> >>problems may all >> >>>be gone with the current version. One potential problem >> >>comes to mind >> >>>is, if TR-ID 2 times out _and_ was never presented to the >> >>recipient, >> >>>TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >> >>falsely be >> >>>treated as a duplicate. Now, I am not sure this can really happen >>>assuming TCP connections all the way. If the receiving peer is >>>overloaded, but recovers well enough to process TR-ID 3, >> >>then TR-ID 2 >> >>>will most likely get processed first anyway, wouldn't it? >>> >>> Does anyone recall a problem with requiring ordered, >> >>contiguous TR-ID >> >>>values, and allowing the receiving peer to notice >> >>discrepancies, that is >> >>>still relevant? >>> >>> >>> >>>>Cheers, >>>>Aki >>>> >>>>ext Ben Campbell wrote: >>>> >>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>> >>>>>>I'm not certain a time period is really necessary. I >> >>think this can >> >>>>>>be local option. >>>>>> >>>>>>Even uniqueness across streams isn't *required*, though >> >>it would be >> >>>>>>helpful. Instead, we can simply introduce an error >> >>response to be >> >>>>>>used when a duplicate is detected and supressed. If it >> >>was supressed >> >>>>>>in error because the sender duplicated a TR-ID from >> >>another stream, >> >>>>>>the sender would then know to recover. >>>>>> >>>>>>But I agree that some further clarification on TR-ID uniqueness >>>>>>could be helpful. >>>>>> >>>>> >>>>>If TR-ID is not required to be unique across sessions, >> >>and you allow >> >>>>>clients to attempt to find duplicate messages using TR-ID across >>>>>sessions, then you introduce the possibility of false detection >>>>>caused by TR-ID collisions. This seems bad to me. >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>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 exim@www1.ietf.org Mon Nov 10 20:56:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29184 for ; Mon, 10 Nov 2003 20:56:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlI-0005Xi-H4 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 20:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB1u845021300 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 20:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlI-0005XT-CP for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 20:56:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29139; Mon, 10 Nov 2003 20:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KE-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KA-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlA-0005RD-Np; Mon, 10 Nov 2003 20:56:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNkJ-0005Qf-05 for simple@optimus.ietf.org; Mon, 10 Nov 2003 20:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29110 for ; Mon, 10 Nov 2003 20:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNkG-0002JT-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:04 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJNkF-0002JQ-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:03 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAB1spIc082451; Mon, 10 Nov 2003 19:55:02 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FAF0F47.2090301@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <3FAC1882.7070605@dynamicsoft.com> In-Reply-To: <3FAC1882.7070605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 09 Nov 2003 22:08:39 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Orit, > > Some comments on: > http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-00.txt > > Generally, I do think we need something like this. It seems particularly > useful in environments where the list is not syncrhonized with the > network, but for which we want to get the benefits of list > subscriptions, in terms of reducing overhead. > > Firstly, this feels to me like it has a lot in common with the filter > work. Both this and the filter work use body objects to push policy > about the subscription to the server. Both have needs for updates to > these policy objects during the lifetime of the subscriptions. Both have > similar lifecycle managamenet requirements. Both provide details on > exactly what the subscription is for. Have you considered trying to > unify this with the filter work? Indeed, it might be useful to start off > with some requirements to define what we want to do here, we may not all > be on the same page. > > Secondly, one big question is - what is the request URI? I can see > several options: > > (1) its a well-known service URI, for example, sip:adhoclist@domain.com, > where the server knows that for any subscriptions to sip:adhoclist@ domain>, it means that the subscription has its contents in the body > > (2) its a SIP URI that doesnt match any existing resource in the domain. > Thus, the act of subscribing basically creates that resource as a list > resource > > (3) its a CID URI, referring to the list in the body of the request > > > I think you have (2) in mind. But, I'm not sure thats the right way to go. > > Thirdly, you talk about all subscribed parties to the list receiving a > notify when the list content changes: > >> When a resource is added to /deleted from the list, the RLS SHOULD >> generate a NOTIFY as if the list had been updated by any possible >> out-of-band means and in accordance with the notification mechanism >> and format established for this list. The updated information SHOULD >> be sent to all the parties being subscribed to this list (including >> the "list-owner"). > > > I dont get this. I thought that an ad-hoc list would be scoped to the > subscription, in which case, there wouldnt be any other subscribers. Am > I missing something? There are also some statements about uniquely naming the list, which only seem to make sense to me if the list is expected to be used outside of the dialog. > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 21:44:40 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29141; Mon, 10 Nov 2003 20:55:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KH-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJNlE-0002KB-00; Mon, 10 Nov 2003 20:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNlB-0005RV-Dd; Mon, 10 Nov 2003 20:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJNkQ-0005Qm-Ll for simple@optimus.ietf.org; Mon, 10 Nov 2003 20:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29113 for ; Mon, 10 Nov 2003 20:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJNkO-0002Jf-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:12 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJNkN-0002JW-00 for simple@ietf.org; Mon, 10 Nov 2003 20:55:11 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAB1t3Ic082480; Mon, 10 Nov 2003 19:55:04 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB04128.2020103@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 19:53:44 -0600 Content-Transfer-Encoding: 7bit In spite of the fact I keep letting myself get trapped into talking about retransmitting, I think I agree. If one attempt fails, it seems highly unlikely another attempt will suddenly succeed. hisham.khartabil@nokia.com wrote: > Again I ask: why is there a need for retransmission? As I said earlier, if a message fails (timeout or 5xx), the end user gets presented with this error and it is up to him/her to send it again. > > If it was a long message and a timeout has occurred, then only the user can decide to send it again (again I'm pointing out that long messages can wrongly time out) > > /Hisham > > >>-----Original Message----- >>From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Tuesday, November 11, 2003 12:27 AM >>To: Ben Campbell >>Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 - message retry >> >> >>Its true that within a given session it should be sufficient to >>distinguish between the currently pending messages. So TR-IDs for >>acknowledged messages could be recycled. >> >>OTOH, without some tweaks that makes the problem of failing over to >>another session harder. >> >>This could perhaps be handled by making a two-part TR-ID: >>.. So when a session is established for the >>first time, >>ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>fail over >>to a new session, then ids for new messages are 2.1, 2.2, ..., but >>retransmissions of old ones would still carry their original TR-ID. >> >>A recipient that supports duplicate suppression would need to >>remember >>the ids of messages processed until certain the response had been >>received by the sender. This could be handled a number of >>different ways: >>- reuse of a TR-ID in the *same* session isn't a retransmission. It >> redefines what message it applies to. >>- if a request is sent in the other direction, any responses sent >> prior to it can be inferred to have been received, so the messages >> corresponding to those responses will no longer be eligible for >> retransmission. >>- the timeout interval for messages puts an upper bound on how >> long one needs to be prepared to deal with retransmissions of >> a message. >> >> Paul >> >>Ben Campbell wrote: >> >>>Aki Niemi wrote: >>> >>> >>>>Hi, >>>> >>>>At this point I'm really confused about the true meaning for TR-ID. >>>> >>>>The current draft reads to me that the TR-ID should be >> >>unique within a >> >>>>session, but there still isn't any duplicate suppression on the >>>>recipient side. If this is the case, I don't even see why >> >>TR-ID needs >> >>>>to be unique within a session. It would seem enough for >> >>the sender not >> >>>>to have TR-ID collisions occur within the set of *pending* >> >>requests. >> >>>>in other words, the TR-ID is opaque to the recipient - >> >>whatever the 5 >> >>>>request had is used in the response. >>> >>> >>>The real requirement for the current usage is exactly as >> >>you say, that >> >>>is, no collisions within the set of pending requests. >> >>Making them unique >> >>>inside a session simply seemed the easiest way to enforce this. >>> >>> >>>>Having said that, I think TR-ID is not working to its full >> >>potential, >> >>>>and thus I have a new proposal. >>>> >>>>Let's make TR-ID a simple counter. Each session starts >> >>from zero, and >> >>>>each new message increments this counter. We can come up with a >>>>reasonable resolution for this counter; x seems as good a value as >>>>any. When the counter hits x, it is reset to zero. >>>>The good thing is that we get duplicate detection without the >>>>recipient having to remember all used TR-IDs within a >> >>session, but it >> >>>>suffices to maintain this unidirectional counter on each end. >>>> >>>>Whatever the resolution will be, it seems a reasonable >> >>limitation to >> >>>>say that a sender can only have x pending requests at a time. >>> >>> >>>This is interesting. We originally avoided this approach due to >>>potential problems with shared connections, etc. These >> >>problems may all >> >>>be gone with the current version. One potential problem >> >>comes to mind >> >>>is, if TR-ID 2 times out _and_ was never presented to the >> >>recipient, >> >>>TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >> >>falsely be >> >>>treated as a duplicate. Now, I am not sure this can really happen >>>assuming TCP connections all the way. If the receiving peer is >>>overloaded, but recovers well enough to process TR-ID 3, >> >>then TR-ID 2 >> >>>will most likely get processed first anyway, wouldn't it? >>> >>> Does anyone recall a problem with requiring ordered, >> >>contiguous TR-ID >> >>>values, and allowing the receiving peer to notice >> >>discrepancies, that is >> >>>still relevant? >>> >>> >>> >>>>Cheers, >>>>Aki >>>> >>>>ext Ben Campbell wrote: >>>> >>>> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>> >>>>>>I'm not certain a time period is really necessary. I >> >>think this can >> >>>>>>be local option. >>>>>> >>>>>>Even uniqueness across streams isn't *required*, though >> >>it would be >> >>>>>>helpful. Instead, we can simply introduce an error >> >>response to be >> >>>>>>used when a duplicate is detected and supressed. If it >> >>was supressed >> >>>>>>in error because the sender duplicated a TR-ID from >> >>another stream, >> >>>>>>the sender would then know to recover. >>>>>> >>>>>>But I agree that some further clarification on TR-ID uniqueness >>>>>>could be helpful. >>>>>> >>>>> >>>>>If TR-ID is not required to be unique across sessions, >> >>and you allow >> >>>>>clients to attempt to find duplicate messages using TR-ID across >>>>>sessions, then you introduce the possibility of false detection >>>>>caused by TR-ID collisions. This seems bad to me. >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>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-admin@ietf.org Mon Nov 10 22:05:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01887; Mon, 10 Nov 2003 22:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOqx-0003TT-00; Mon, 10 Nov 2003 22:06:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJOqw-0003TQ-00; Mon, 10 Nov 2003 22:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOqw-0001pe-BX; Mon, 10 Nov 2003 22:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOqf-0001pC-QW for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:05:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01875 for ; Mon, 10 Nov 2003 22:05:31 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOqc-0003TB-00 for simple@ietf.org; Mon, 10 Nov 2003 22:05:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJOqc-0003T8-00 for simple@ietf.org; Mon, 10 Nov 2003 22:05:42 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB35gJ03605 for ; Tue, 11 Nov 2003 05:05:42 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 05:05:41 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 05:05:41 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Nov 2003 05:05:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 Thread-Index: AcOnzhN+jEF1WPjUSJ2CKaqh3ZHFSgAFGOEg To: Cc: X-OriginalArrivalTime: 11 Nov 2003 03:05:41.0736 (UTC) FILETIME=[B0DEBE80:01C3A800] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 05:05:41 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, November 10, 2003 11:03 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >>-----Original Message----- > >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: Friday, November 07, 2003 7:16 PM > >>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] Comments on message-sessions-02 > >> > >> > >>Hi--I addressed some points in separate emails. Others inline: > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>[...] > >> > >> > >>>- Section 4:=20 > >=20 > > [snip] > >=20 > >>> - This section also talks about inactivity timer, and=20 > >> > >>says that that hosting device invalidates the session state=20 > >>when timer expires. Why is it just the hosting device? > >> > >>Let me turn that question around. Why would any other=20 > device need to?=20 > >>When the hosting device closes the session, the endpoints=20 > >>will learn of=20 > >>it in short order as they get their connections closed. So will a=20 > >>visiting relay, for that matter (although I do think we=20 > have an open=20 > >>item on whether visiting relays should have to worry about=20 > the timer.) > >=20 > >=20 > > Why does the visiting peer have an inactivity timer then?=20 > It also needs to clear up state on its end when the timer fires. > >=20 >=20 > It needs it so that it knows when and if it needs to send traffic to=20 > avoid having the host device kill the session. well, that was my point. The text in that specific section omits this = information about the visitor. >=20 > >=20 > >>>- Section 5.1: > >>> - Is this section normative? It have normative text like=20 > >> > >>SHOULD and SHOULD not. > >> > >>Yes, section 5.1 is intended to be normative, although it=20 > contains no=20 > >>statements stronger than SHOULD. But we mean those SHOULDs=20 > >>just as much=20 > >>as any other SHOULDs in the document. :-) > >=20 > >=20 > >=20 > > maybe those SHOULDs and SHOULD NOTs should be changed to=20 > lower case :) > >=20 >=20 > I am not sure of the point. You are suggesting they should not be=20 > normative? Why? I think this whole section 5.1 is just informative. EG: "Therefore = relays SHOULD NOT be used indiscriminately", how is that a protocol = normative text? >=20 > >=20 > >>>- Section 5.2: > >>> - Open issue: the attribute accept-type can be used to=20 > >> > >>restrict the use of a message session. So if a session was=20 > >>created to send mpeg video. The accept-types attribute should=20 > >>only carry that mime-type. In this way, the other endpoint=20 > >>does not use that session to send normal messages. > >> > >>That is an interesting approach. But I think we may have overlap in=20 > >>types that are allowed on an IM session, and types that are=20 > >>allowed on a=20 > >>file transfer session. What if I want to transfer a large=20 > >>file of type=20 > >>text/plain? > >=20 > >=20 > > Excuse my ignorance, but don't files have their own=20 > mime-type text/something? > >=20 >=20 > It may be my own ignorance speaking, but I would expect a=20 > text file to=20 > have a mime type of text/plain. Which is also a reasonable=20 > type for an IM. text/plain does not tell you there is a file attached. I believe it has = its own mime type. > >> > >>That does not seem to allow for something like "a=3Daccept-types:=20 > >>message/cpim text/plain *", which is semantically meaningful. I can=20 > >>change the syntax to only allow one "*", but do we really=20 > >>care? "* * *"=20 > >>may be silly, but it can still be interpreted reasonably. > >=20 > >=20 > >=20 > > what does it mean to say "a=3Daccept-types: message/cpim=20 > text/plain *" ? * is enough in this case and encapsulates =20 > message/cpim and text/plain. Does your silence on this issue means you agree? > >=20 > >=20 > >>[...] > >> > >> > >>>- Section 7.1.2: > >>> - Why is there text describing the use of SRV if no port=20 > >> > >>is present? The port is mandatory and therefore resolving=20 > >>should fail if no port is present. INVITE requests would then=20 > >>be rejected. If we want SRV, then we need to relax the MUST=20 > for port. > >> > >>It is not mandatory for a URL that designates a relay that is=20 > >>handed to=20 > >>an endpoint out-of-band. (For example, when a user configures=20 > >>a client=20 > >>to use a relay.) > >=20 > >=20 > > Section 7.1 says:=20 > >=20 > > "An MSRP URL server part identifies the hosting device of an MSRP > > session. If the server part contains a numeric IP=20 > address, it MUST > > also contain a port" > >=20 > > So maybe you need to add text differentiating between a=20 > relay URL and a session URL. Also here?? /Hisham > >=20 > >=20 > > /Hisham=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 22:06:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01904 for ; Mon, 10 Nov 2003 22:06:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOr1-0001qb-Ga for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB367hc007095 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOr1-0001qL-Cx for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01887; Mon, 10 Nov 2003 22:05:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOqx-0003TT-00; Mon, 10 Nov 2003 22:06:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJOqw-0003TQ-00; Mon, 10 Nov 2003 22:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOqw-0001pe-BX; Mon, 10 Nov 2003 22:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJOqf-0001pC-QW for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:05:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01875 for ; Mon, 10 Nov 2003 22:05:31 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJOqc-0003TB-00 for simple@ietf.org; Mon, 10 Nov 2003 22:05:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJOqc-0003T8-00 for simple@ietf.org; Mon, 10 Nov 2003 22:05:42 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB35gJ03605 for ; Tue, 11 Nov 2003 05:05:42 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 05:05:41 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 05:05:41 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 11 Nov 2003 05:05:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AD@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 Thread-Index: AcOnzhN+jEF1WPjUSJ2CKaqh3ZHFSgAFGOEg To: Cc: X-OriginalArrivalTime: 11 Nov 2003 03:05:41.0736 (UTC) FILETIME=[B0DEBE80:01C3A800] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 05:05:41 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, November 10, 2003 11:03 PM > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >>-----Original Message----- > >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: Friday, November 07, 2003 7:16 PM > >>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>Cc: simple@ietf.org > >>Subject: Re: [Simple] Comments on message-sessions-02 > >> > >> > >>Hi--I addressed some points in separate emails. Others inline: > >> > >>hisham.khartabil@nokia.com wrote: > >> > >>[...] > >> > >> > >>>- Section 4:=20 > >=20 > > [snip] > >=20 > >>> - This section also talks about inactivity timer, and=20 > >> > >>says that that hosting device invalidates the session state=20 > >>when timer expires. Why is it just the hosting device? > >> > >>Let me turn that question around. Why would any other=20 > device need to?=20 > >>When the hosting device closes the session, the endpoints=20 > >>will learn of=20 > >>it in short order as they get their connections closed. So will a=20 > >>visiting relay, for that matter (although I do think we=20 > have an open=20 > >>item on whether visiting relays should have to worry about=20 > the timer.) > >=20 > >=20 > > Why does the visiting peer have an inactivity timer then?=20 > It also needs to clear up state on its end when the timer fires. > >=20 >=20 > It needs it so that it knows when and if it needs to send traffic to=20 > avoid having the host device kill the session. well, that was my point. The text in that specific section omits this = information about the visitor. >=20 > >=20 > >>>- Section 5.1: > >>> - Is this section normative? It have normative text like=20 > >> > >>SHOULD and SHOULD not. > >> > >>Yes, section 5.1 is intended to be normative, although it=20 > contains no=20 > >>statements stronger than SHOULD. But we mean those SHOULDs=20 > >>just as much=20 > >>as any other SHOULDs in the document. :-) > >=20 > >=20 > >=20 > > maybe those SHOULDs and SHOULD NOTs should be changed to=20 > lower case :) > >=20 >=20 > I am not sure of the point. You are suggesting they should not be=20 > normative? Why? I think this whole section 5.1 is just informative. EG: "Therefore = relays SHOULD NOT be used indiscriminately", how is that a protocol = normative text? >=20 > >=20 > >>>- Section 5.2: > >>> - Open issue: the attribute accept-type can be used to=20 > >> > >>restrict the use of a message session. So if a session was=20 > >>created to send mpeg video. The accept-types attribute should=20 > >>only carry that mime-type. In this way, the other endpoint=20 > >>does not use that session to send normal messages. > >> > >>That is an interesting approach. But I think we may have overlap in=20 > >>types that are allowed on an IM session, and types that are=20 > >>allowed on a=20 > >>file transfer session. What if I want to transfer a large=20 > >>file of type=20 > >>text/plain? > >=20 > >=20 > > Excuse my ignorance, but don't files have their own=20 > mime-type text/something? > >=20 >=20 > It may be my own ignorance speaking, but I would expect a=20 > text file to=20 > have a mime type of text/plain. Which is also a reasonable=20 > type for an IM. text/plain does not tell you there is a file attached. I believe it has = its own mime type. > >> > >>That does not seem to allow for something like "a=3Daccept-types:=20 > >>message/cpim text/plain *", which is semantically meaningful. I can=20 > >>change the syntax to only allow one "*", but do we really=20 > >>care? "* * *"=20 > >>may be silly, but it can still be interpreted reasonably. > >=20 > >=20 > >=20 > > what does it mean to say "a=3Daccept-types: message/cpim=20 > text/plain *" ? * is enough in this case and encapsulates =20 > message/cpim and text/plain. Does your silence on this issue means you agree? > >=20 > >=20 > >>[...] > >> > >> > >>>- Section 7.1.2: > >>> - Why is there text describing the use of SRV if no port=20 > >> > >>is present? The port is mandatory and therefore resolving=20 > >>should fail if no port is present. INVITE requests would then=20 > >>be rejected. If we want SRV, then we need to relax the MUST=20 > for port. > >> > >>It is not mandatory for a URL that designates a relay that is=20 > >>handed to=20 > >>an endpoint out-of-band. (For example, when a user configures=20 > >>a client=20 > >>to use a relay.) > >=20 > >=20 > > Section 7.1 says:=20 > >=20 > > "An MSRP URL server part identifies the hosting device of an MSRP > > session. If the server part contains a numeric IP=20 > address, it MUST > > also contain a port" > >=20 > > So maybe you need to add text differentiating between a=20 > relay URL and a session URL. Also here?? /Hisham > >=20 > >=20 > > /Hisham=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 22:32:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02658; Mon, 10 Nov 2003 22:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003lD-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003l9-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPH2-0003BR-L0; Mon, 10 Nov 2003 22:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPGI-00032Q-4Y for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:32:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02604 for ; Mon, 10 Nov 2003 22:31:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGE-0003kU-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGE-0003kR-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB3WAc12262 for ; Tue, 11 Nov 2003 05:32:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 05:32:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 05:32:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AE@esebe019.ntc.nokia.com> Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOlfGBg494rMckvRIq+0/koUzddYACh9SvA To: , X-OriginalArrivalTime: 11 Nov 2003 03:32:10.0155 (UTC) FILETIME=[63A43FB0:01C3A804] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 05:32:07 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: Saturday, November 08, 2003 12:11 AM > To: Simple WG > Subject: [Simple] ad-hoc list subscriptions >=20 >=20 > Orit, >=20 > Some comments on: > http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-l > ist-00.txt >=20 > Generally, I do think we need something like this. It seems=20 > particularly useful in environments where the list is not=20 > syncrhonized=20 > with the network, but for which we want to get the benefits of list=20 > subscriptions, in terms of reducing overhead. >=20 > Firstly, this feels to me like it has a lot in common with the filter=20 > work. Both this and the filter work use body objects to push policy=20 > about the subscription to the server. Both have needs for updates to=20 > these policy objects during the lifetime of the subscriptions. Both=20 > have similar lifecycle managamenet requirements. Both provide details=20 > on exactly what the subscription is for. Have you considered=20 > trying to=20 > unify this with the filter work? Indeed, it might be useful to start=20 > off with some requirements to define what we want to do here, we may=20 > not all be on the same page. I'm not sure how they can be unified. I actually don't see the link = between the two. Regards, Hisham >=20 > Secondly, one big question is - what is the request URI? I can see=20 > several options: >=20 > (1) its a well-known service URI, for example,=20 > sip:adhoclist@domain.com, where the server knows that for any=20 > subscriptions to sip:adhoclist@, it means that the=20 > subscription has its contents in the body >=20 > (2) its a SIP URI that doesnt match any existing resource in the=20 > domain. Thus, the act of subscribing basically creates that resource=20 > as a list resource >=20 > (3) its a CID URI, referring to the list in the body of the request >=20 >=20 > I think you have (2) in mind. But, I'm not sure thats the=20 > right way to=20 > go. >=20 > Thirdly, you talk about all subscribed parties to the list=20 > receiving a=20 > notify when the list content changes: >=20 > > When a resource is added to /deleted from the list, the RLS SHOULD > > generate a NOTIFY as if the list had been updated by any possible > > out-of-band means and in accordance with the=20 > notification mechanism > > and format established for this list. The updated=20 > information SHOULD > > be sent to all the parties being subscribed to this list=20 > (including > > the "list-owner"). >=20 > I dont get this. I thought that an ad-hoc list would be scoped to the=20 > subscription, in which case, there wouldnt be any other subscribers.=20 > Am I missing something? >=20 > Thanks, > Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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 exim@www1.ietf.org Mon Nov 10 22:33:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02711 for ; Mon, 10 Nov 2003 22:33:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHD-0003FQ-4d for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:33:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3XBrN012477 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:33:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHC-0003Ew-UK for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:33:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02660; Mon, 10 Nov 2003 22:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003lG-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003lA-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPH3-0003BZ-6B; Mon, 10 Nov 2003 22:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPGX-00034Y-RF for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:32:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02611 for ; Mon, 10 Nov 2003 22:32:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGU-0003ke-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJPGT-0003kb-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAB3WEIc090732; Mon, 10 Nov 2003 21:32:25 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB0583C.2060302@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB7017973AD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973AD@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 21:32:12 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, November 10, 2003 11:03 PM >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>>-----Original Message----- >>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>Sent: Friday, November 07, 2003 7:16 PM >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>Cc: simple@ietf.org >>>>Subject: Re: [Simple] Comments on message-sessions-02 >>>> >>>> >>>>Hi--I addressed some points in separate emails. Others inline: >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>>[...] >>>> >>>> >>>> >>>>>- Section 4: >>> >>>[snip] >>> >>> >>>>> - This section also talks about inactivity timer, and >>>> >>>>says that that hosting device invalidates the session state >>>>when timer expires. Why is it just the hosting device? >>>> >>>>Let me turn that question around. Why would any other >> >>device need to? >> >>>>When the hosting device closes the session, the endpoints >>>>will learn of >>>>it in short order as they get their connections closed. So will a >>>>visiting relay, for that matter (although I do think we >> >>have an open >> >>>>item on whether visiting relays should have to worry about >> >>the timer.) >> >>> >>>Why does the visiting peer have an inactivity timer then? >> >>It also needs to clear up state on its end when the timer fires. >> >>It needs it so that it knows when and if it needs to send traffic to >>avoid having the host device kill the session. > > > > well, that was my point. The text in that specific section omits this information about the visitor. OK, if the point is that the text needs clarification, then I can buy it. > > >>>>>- Section 5.1: >>>>> - Is this section normative? It have normative text like >>>> >>>>SHOULD and SHOULD not. >>>> >>>>Yes, section 5.1 is intended to be normative, although it >> >>contains no >> >>>>statements stronger than SHOULD. But we mean those SHOULDs >>>>just as much >>>>as any other SHOULDs in the document. :-) >>> >>> >>> >>>maybe those SHOULDs and SHOULD NOTs should be changed to >> >>lower case :) >> >>I am not sure of the point. You are suggesting they should not be >>normative? Why? > > > I think this whole section 5.1 is just informative. EG: "Therefore relays SHOULD NOT be used indiscriminately", how is that a protocol normative text? > We have had normative text in "usage guidlines" in the past. I agree it is rather odd. I am not opposed to treating it as informative, but will not be surprised if others are. > >>>>>- Section 5.2: >>>>> - Open issue: the attribute accept-type can be used to >>>> >>>>restrict the use of a message session. So if a session was >>>>created to send mpeg video. The accept-types attribute should >>>>only carry that mime-type. In this way, the other endpoint >>>>does not use that session to send normal messages. >>>> >>>>That is an interesting approach. But I think we may have overlap in >>>>types that are allowed on an IM session, and types that are >>>>allowed on a >>>>file transfer session. What if I want to transfer a large >>>>file of type >>>>text/plain? >>> >>> >>>Excuse my ignorance, but don't files have their own >> >>mime-type text/something? >> >>It may be my own ignorance speaking, but I would expect a >>text file to >>have a mime type of text/plain. Which is also a reasonable >>type for an IM. > > > > text/plain does not tell you there is a file attached. I believe it has its own mime type. Anyone else want to comment on this? I am pretty sure you can have a text/plain file--but I will go do some research to make sure I have not gone insane. > > >>>>That does not seem to allow for something like "a=accept-types: >>>>message/cpim text/plain *", which is semantically meaningful. I can >>>>change the syntax to only allow one "*", but do we really >>>>care? "* * *" >>>>may be silly, but it can still be interpreted reasonably. >>> >>> >>> >>>what does it mean to say "a=accept-types: message/cpim >> >>text/plain *" ? * is enough in this case and encapsulates >>message/cpim and text/plain. > > > Does your silence on this issue means you agree? > No, it means I did not scroll down far enough. "message/cpim text/plain *" is explicitly described to mean that you can attempt any format, but you should prefer message/cpim or text/plain. > >>> >>>>[...] >>>> >>>> >>>> >>>>>- Section 7.1.2: >>>>> - Why is there text describing the use of SRV if no port >>>> >>>>is present? The port is mandatory and therefore resolving >>>>should fail if no port is present. INVITE requests would then >>>>be rejected. If we want SRV, then we need to relax the MUST >> >>for port. >> >>>>It is not mandatory for a URL that designates a relay that is >>>>handed to >>>>an endpoint out-of-band. (For example, when a user configures >>>>a client >>>>to use a relay.) >>> >>> >>>Section 7.1 says: >>> >>>"An MSRP URL server part identifies the hosting device of an MSRP >>> session. If the server part contains a numeric IP >> >>address, it MUST >> >>> also contain a port" >>> >>>So maybe you need to add text differentiating between a >> >>relay URL and a session URL. > > > Also here?? Also a scrolling error. It's are the same kind of URL. There is text that says that the port must be included if delivered in an sdp offer/answer. There is no such text for other usages. > > /Hisham > > > >>> >>>/Hisham >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 10 22:33:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02752; Mon, 10 Nov 2003 22:33:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPI0-0003ma-00; Mon, 10 Nov 2003 22:34:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPI0-0003mX-00; Mon, 10 Nov 2003 22:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPI1-0003Qg-OR; Mon, 10 Nov 2003 22:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHe-0003PM-DQ for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:33:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02700 for ; Mon, 10 Nov 2003 22:33:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPHa-0003lo-00 for simple@ietf.org; Mon, 10 Nov 2003 22:33:34 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJPHa-0003l7-00 for simple@ietf.org; Mon, 10 Nov 2003 22:33:34 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAB3X2Gd013021; Mon, 10 Nov 2003 21:33:02 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 21:33:02 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Ben Campbell Cc: simple@ietf.org Subject: RE: [Simple] Comments on message-sessions-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 21:32:56 -0600 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: > text/plain does not tell you there is a file attached. I > believe it has its own mime type. Errmm... no. The mime type doesn't indicate anything about whether the content is supposed to be rendered to the user or saved to a file. What you're thinking of is Content-Disposition. http://www.ietf.org/rfc/rfc2183.txt So, if you wanted to hint that a text/plain payload should be saved instead of rendered, I would submit that adding a Content-Disposition header to MSRP would achieve the effect you want. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 22:34:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02802 for ; Mon, 10 Nov 2003 22:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPI5-0003XR-JD for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:34:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3Y5ZN013595 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPI5-0003XC-Dl for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:34:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02752; Mon, 10 Nov 2003 22:33:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPI0-0003ma-00; Mon, 10 Nov 2003 22:34:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPI0-0003mX-00; Mon, 10 Nov 2003 22:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPI1-0003Qg-OR; Mon, 10 Nov 2003 22:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHe-0003PM-DQ for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:33:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02700 for ; Mon, 10 Nov 2003 22:33:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPHa-0003lo-00 for simple@ietf.org; Mon, 10 Nov 2003 22:33:34 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJPHa-0003l7-00 for simple@ietf.org; Mon, 10 Nov 2003 22:33:34 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAB3X2Gd013021; Mon, 10 Nov 2003 21:33:02 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 21:33:02 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'hisham.khartabil@nokia.com'" , Ben Campbell Cc: simple@ietf.org Subject: RE: [Simple] Comments on message-sessions-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 21:32:56 -0600 hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: > text/plain does not tell you there is a file attached. I > believe it has its own mime type. Errmm... no. The mime type doesn't indicate anything about whether the content is supposed to be rendered to the user or saved to a file. What you're thinking of is Content-Disposition. http://www.ietf.org/rfc/rfc2183.txt So, if you wanted to hint that a text/plain payload should be saved instead of rendered, I would submit that adding a Content-Disposition header to MSRP would achieve the effect you want. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 10 23:33:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02710 for ; Mon, 10 Nov 2003 22:33:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHD-0003FH-2C for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:33:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3XAK6012463 for simple-archive@odin.ietf.org; Mon, 10 Nov 2003 22:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPHC-0003Ev-TU for simple-web-archive@optimus.ietf.org; Mon, 10 Nov 2003 22:33:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02658; Mon, 10 Nov 2003 22:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003lD-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003l9-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPH2-0003BR-L0; Mon, 10 Nov 2003 22:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPGI-00032Q-4Y for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:32:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02604 for ; Mon, 10 Nov 2003 22:31:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGE-0003kU-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGE-0003kR-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:10 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB3WAc12262 for ; Tue, 11 Nov 2003 05:32:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 05:32:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 05:32:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AE@esebe019.ntc.nokia.com> Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOlfGBg494rMckvRIq+0/koUzddYACh9SvA To: , X-OriginalArrivalTime: 11 Nov 2003 03:32:10.0155 (UTC) FILETIME=[63A43FB0:01C3A804] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 05:32:07 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: Saturday, November 08, 2003 12:11 AM > To: Simple WG > Subject: [Simple] ad-hoc list subscriptions >=20 >=20 > Orit, >=20 > Some comments on: > http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-l > ist-00.txt >=20 > Generally, I do think we need something like this. It seems=20 > particularly useful in environments where the list is not=20 > syncrhonized=20 > with the network, but for which we want to get the benefits of list=20 > subscriptions, in terms of reducing overhead. >=20 > Firstly, this feels to me like it has a lot in common with the filter=20 > work. Both this and the filter work use body objects to push policy=20 > about the subscription to the server. Both have needs for updates to=20 > these policy objects during the lifetime of the subscriptions. Both=20 > have similar lifecycle managamenet requirements. Both provide details=20 > on exactly what the subscription is for. Have you considered=20 > trying to=20 > unify this with the filter work? Indeed, it might be useful to start=20 > off with some requirements to define what we want to do here, we may=20 > not all be on the same page. I'm not sure how they can be unified. I actually don't see the link = between the two. Regards, Hisham >=20 > Secondly, one big question is - what is the request URI? I can see=20 > several options: >=20 > (1) its a well-known service URI, for example,=20 > sip:adhoclist@domain.com, where the server knows that for any=20 > subscriptions to sip:adhoclist@, it means that the=20 > subscription has its contents in the body >=20 > (2) its a SIP URI that doesnt match any existing resource in the=20 > domain. Thus, the act of subscribing basically creates that resource=20 > as a list resource >=20 > (3) its a CID URI, referring to the list in the body of the request >=20 >=20 > I think you have (2) in mind. But, I'm not sure thats the=20 > right way to=20 > go. >=20 > Thirdly, you talk about all subscribed parties to the list=20 > receiving a=20 > notify when the list content changes: >=20 > > When a resource is added to /deleted from the list, the RLS SHOULD > > generate a NOTIFY as if the list had been updated by any possible > > out-of-band means and in accordance with the=20 > notification mechanism > > and format established for this list. The updated=20 > information SHOULD > > be sent to all the parties being subscribed to this list=20 > (including > > the "list-owner"). >=20 > I dont get this. I thought that an ad-hoc list would be scoped to the=20 > subscription, in which case, there wouldnt be any other subscribers.=20 > Am I missing something? >=20 > Thanks, > Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=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-admin@ietf.org Mon Nov 10 23:33:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02660; Mon, 10 Nov 2003 22:32:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003lG-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJPH8-0003lA-00; Mon, 10 Nov 2003 22:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPH3-0003BZ-6B; Mon, 10 Nov 2003 22:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPGX-00034Y-RF for simple@optimus.ietf.org; Mon, 10 Nov 2003 22:32:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02611 for ; Mon, 10 Nov 2003 22:32:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPGU-0003ke-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJPGT-0003kb-00 for simple@ietf.org; Mon, 10 Nov 2003 22:32:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAB3WEIc090732; Mon, 10 Nov 2003 21:32:25 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB0583C.2060302@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB7017973AD@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973AD@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 10 Nov 2003 21:32:12 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, November 10, 2003 11:03 PM >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>>-----Original Message----- >>>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>Sent: Friday, November 07, 2003 7:16 PM >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>Cc: simple@ietf.org >>>>Subject: Re: [Simple] Comments on message-sessions-02 >>>> >>>> >>>>Hi--I addressed some points in separate emails. Others inline: >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>>[...] >>>> >>>> >>>> >>>>>- Section 4: >>> >>>[snip] >>> >>> >>>>> - This section also talks about inactivity timer, and >>>> >>>>says that that hosting device invalidates the session state >>>>when timer expires. Why is it just the hosting device? >>>> >>>>Let me turn that question around. Why would any other >> >>device need to? >> >>>>When the hosting device closes the session, the endpoints >>>>will learn of >>>>it in short order as they get their connections closed. So will a >>>>visiting relay, for that matter (although I do think we >> >>have an open >> >>>>item on whether visiting relays should have to worry about >> >>the timer.) >> >>> >>>Why does the visiting peer have an inactivity timer then? >> >>It also needs to clear up state on its end when the timer fires. >> >>It needs it so that it knows when and if it needs to send traffic to >>avoid having the host device kill the session. > > > > well, that was my point. The text in that specific section omits this information about the visitor. OK, if the point is that the text needs clarification, then I can buy it. > > >>>>>- Section 5.1: >>>>> - Is this section normative? It have normative text like >>>> >>>>SHOULD and SHOULD not. >>>> >>>>Yes, section 5.1 is intended to be normative, although it >> >>contains no >> >>>>statements stronger than SHOULD. But we mean those SHOULDs >>>>just as much >>>>as any other SHOULDs in the document. :-) >>> >>> >>> >>>maybe those SHOULDs and SHOULD NOTs should be changed to >> >>lower case :) >> >>I am not sure of the point. You are suggesting they should not be >>normative? Why? > > > I think this whole section 5.1 is just informative. EG: "Therefore relays SHOULD NOT be used indiscriminately", how is that a protocol normative text? > We have had normative text in "usage guidlines" in the past. I agree it is rather odd. I am not opposed to treating it as informative, but will not be surprised if others are. > >>>>>- Section 5.2: >>>>> - Open issue: the attribute accept-type can be used to >>>> >>>>restrict the use of a message session. So if a session was >>>>created to send mpeg video. The accept-types attribute should >>>>only carry that mime-type. In this way, the other endpoint >>>>does not use that session to send normal messages. >>>> >>>>That is an interesting approach. But I think we may have overlap in >>>>types that are allowed on an IM session, and types that are >>>>allowed on a >>>>file transfer session. What if I want to transfer a large >>>>file of type >>>>text/plain? >>> >>> >>>Excuse my ignorance, but don't files have their own >> >>mime-type text/something? >> >>It may be my own ignorance speaking, but I would expect a >>text file to >>have a mime type of text/plain. Which is also a reasonable >>type for an IM. > > > > text/plain does not tell you there is a file attached. I believe it has its own mime type. Anyone else want to comment on this? I am pretty sure you can have a text/plain file--but I will go do some research to make sure I have not gone insane. > > >>>>That does not seem to allow for something like "a=accept-types: >>>>message/cpim text/plain *", which is semantically meaningful. I can >>>>change the syntax to only allow one "*", but do we really >>>>care? "* * *" >>>>may be silly, but it can still be interpreted reasonably. >>> >>> >>> >>>what does it mean to say "a=accept-types: message/cpim >> >>text/plain *" ? * is enough in this case and encapsulates >>message/cpim and text/plain. > > > Does your silence on this issue means you agree? > No, it means I did not scroll down far enough. "message/cpim text/plain *" is explicitly described to mean that you can attempt any format, but you should prefer message/cpim or text/plain. > >>> >>>>[...] >>>> >>>> >>>> >>>>>- Section 7.1.2: >>>>> - Why is there text describing the use of SRV if no port >>>> >>>>is present? The port is mandatory and therefore resolving >>>>should fail if no port is present. INVITE requests would then >>>>be rejected. If we want SRV, then we need to relax the MUST >> >>for port. >> >>>>It is not mandatory for a URL that designates a relay that is >>>>handed to >>>>an endpoint out-of-band. (For example, when a user configures >>>>a client >>>>to use a relay.) >>> >>> >>>Section 7.1 says: >>> >>>"An MSRP URL server part identifies the hosting device of an MSRP >>> session. If the server part contains a numeric IP >> >>address, it MUST >> >>> also contain a port" >>> >>>So maybe you need to add text differentiating between a >> >>relay URL and a session URL. > > > Also here?? Also a scrolling error. It's are the same kind of URL. There is text that says that the port must be included if delivered in an sdp offer/answer. There is no such text for other usages. > > /Hisham > > > >>> >>>/Hisham >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 10:43:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06304; Tue, 11 Nov 2003 10:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJafi-0004pi-00; Tue, 11 Nov 2003 10:43:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJafi-0004pX-00; Tue, 11 Nov 2003 10:43:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaeX-0000QV-7t; Tue, 11 Nov 2003 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJadm-0000P5-6G for simple@optimus.ietf.org; Tue, 11 Nov 2003 10:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06284 for ; Tue, 11 Nov 2003 10:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJadj-0004ow-00 for simple@ietf.org; Tue, 11 Nov 2003 10:41:11 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJadi-0004os-00 for simple@ietf.org; Tue, 11 Nov 2003 10:41:10 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2003 07:47:09 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABFeaw5001672; Tue, 11 Nov 2003 07:40:37 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-36.cisco.com [10.86.242.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW93200; Tue, 11 Nov 2003 10:40:35 -0500 (EST) Message-ID: <3FB102F2.8050405@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 10:40:34 -0500 Content-Transfer-Encoding: 7bit I agree that retransmission over the same connection is useless and shouldn't be attempted. The issue is retransmission of messages pending on the old session when switching to a replacement session. That situation can arise if for instance a relay crashes. In that case the endpoint may well recover by establishing a new session and retransmitting any messages not confirmed on the old one. Of course Hisham is right that it is possible to leave the decision to retransmit to the user of the application. This has a couple of problems: - the end user presumably doesn't have access to tools for suppressing duplicates. So in cases where the old message had been process but the response not delivered this will result in a duplicate message. This can be mitigated somewhat by clarifying conversation between the users at the two ends. - automata at one end or the other will be further limited. They are likely to be less tolerant of problems and less able to mitigate the problems via informal communication. Paul Paul Ben Campbell wrote: > In spite of the fact I keep letting myself get trapped into talking > about retransmitting, I think I agree. If one attempt fails, it seems > highly unlikely another attempt will suddenly succeed. > > hisham.khartabil@nokia.com wrote: > >> Again I ask: why is there a need for retransmission? As I said >> earlier, if a message fails (timeout or 5xx), the end user gets >> presented with this error and it is up to him/her to send it again. >> >> If it was a long message and a timeout has occurred, then only the >> user can decide to send it again (again I'm pointing out that long >> messages can wrongly time out) >> >> /Hisham >> >> >>> -----Original Message----- >>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, November 11, 2003 12:27 AM >>> To: Ben Campbell >>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>> simple@ietf.org >>> Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>> >>> >>> Its true that within a given session it should be sufficient to >>> distinguish between the currently pending messages. So TR-IDs for >>> acknowledged messages could be recycled. >>> >>> OTOH, without some tweaks that makes the problem of failing over to >>> another session harder. >>> >>> This could perhaps be handled by making a two-part TR-ID: >>> .. So when a session is established for the first >>> time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>> fail over to a new session, then ids for new messages are 2.1, 2.2, >>> ..., but retransmissions of old ones would still carry their original >>> TR-ID. >>> >>> A recipient that supports duplicate suppression would need to >>> remember the ids of messages processed until certain the response had >>> been received by the sender. This could be handled a number of >>> different ways: >>> - reuse of a TR-ID in the *same* session isn't a retransmission. It >>> redefines what message it applies to. >>> - if a request is sent in the other direction, any responses sent >>> prior to it can be inferred to have been received, so the messages >>> corresponding to those responses will no longer be eligible for >>> retransmission. >>> - the timeout interval for messages puts an upper bound on how >>> long one needs to be prepared to deal with retransmissions of >>> a message. >>> >>> Paul >>> >>> Ben Campbell wrote: >>> >>>> Aki Niemi wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> At this point I'm really confused about the true meaning for TR-ID. >>>>> >>>>> The current draft reads to me that the TR-ID should be >>>> >>> >>> unique within a >>> >>>>> session, but there still isn't any duplicate suppression on the >>>>> recipient side. If this is the case, I don't even see why >>>> >>> >>> TR-ID needs >>> >>>>> to be unique within a session. It would seem enough for >>>> >>> >>> the sender not >>> >>>>> to have TR-ID collisions occur within the set of *pending* >>>> >>> >>> requests. >>> >>>>> in other words, the TR-ID is opaque to the recipient - >>>> >>> >>> whatever the 5 >>> >>>>> request had is used in the response. >>>> >>>> >>>> >>>> The real requirement for the current usage is exactly as >>> >>> >>> you say, that >>> >>>> is, no collisions within the set of pending requests. >>> >>> >>> Making them unique >>> >>>> inside a session simply seemed the easiest way to enforce this. >>>> >>>> >>>>> Having said that, I think TR-ID is not working to its full >>>> >>> >>> potential, >>> >>>>> and thus I have a new proposal. >>>>> >>>>> Let's make TR-ID a simple counter. Each session starts >>>> >>> >>> from zero, and >>> >>>>> each new message increments this counter. We can come up with a >>>>> reasonable resolution for this counter; x seems as good a value as >>>>> any. When the counter hits x, it is reset to zero. >>>>> The good thing is that we get duplicate detection without the >>>>> recipient having to remember all used TR-IDs within a >>>> >>> >>> session, but it >>> >>>>> suffices to maintain this unidirectional counter on each end. >>>>> >>>>> Whatever the resolution will be, it seems a reasonable >>>> >>> >>> limitation to >>> >>>>> say that a sender can only have x pending requests at a time. >>>> >>>> >>>> >>>> This is interesting. We originally avoided this approach due to >>>> potential problems with shared connections, etc. These >>> >>> >>> problems may all >>> >>>> be gone with the current version. One potential problem >>> >>> >>> comes to mind >>> >>>> is, if TR-ID 2 times out _and_ was never presented to the >>> >>> >>> recipient, >>> >>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >>> >>> >>> falsely be >>> >>>> treated as a duplicate. Now, I am not sure this can really happen >>>> assuming TCP connections all the way. If the receiving peer is >>>> overloaded, but recovers well enough to process TR-ID 3, >>> >>> >>> then TR-ID 2 >>> >>>> will most likely get processed first anyway, wouldn't it? >>>> >>>> Does anyone recall a problem with requiring ordered, >>> >>> >>> contiguous TR-ID >>> >>>> values, and allowing the receiving peer to notice >>> >>> >>> discrepancies, that is >>> >>>> still relevant? >>>> >>>> >>>> >>>>> Cheers, >>>>> Aki >>>>> >>>>> ext Ben Campbell wrote: >>>>> >>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>> >>>>>>> I'm not certain a time period is really necessary. I >>>>>> >>> >>> think this can >>> >>>>>>> be local option. >>>>>>> >>>>>>> Even uniqueness across streams isn't *required*, though >>>>>> >>> >>> it would be >>> >>>>>>> helpful. Instead, we can simply introduce an error >>>>>> >>> >>> response to be >>> >>>>>>> used when a duplicate is detected and supressed. If it >>>>>> >>> >>> was supressed >>> >>>>>>> in error because the sender duplicated a TR-ID from >>>>>> >>> >>> another stream, >>> >>>>>>> the sender would then know to recover. >>>>>>> >>>>>>> But I agree that some further clarification on TR-ID uniqueness >>>>>>> could be helpful. >>>>>>> >>>>>> >>>>>> If TR-ID is not required to be unique across sessions, >>>>> >>> >>> and you allow >>> >>>>>> clients to attempt to find duplicate messages using TR-ID across >>>>>> sessions, then you introduce the possibility of false detection >>>>>> caused by TR-ID collisions. This seems bad to me. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 exim@www1.ietf.org Tue Nov 11 10:43:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06388 for ; Tue, 11 Nov 2003 10:43:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJafo-0000WB-TV for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 10:43:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFhKrQ001988 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 10:43:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJafn-0000Vy-9k for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 10:43:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06304; Tue, 11 Nov 2003 10:43:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJafi-0004pi-00; Tue, 11 Nov 2003 10:43:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJafi-0004pX-00; Tue, 11 Nov 2003 10:43:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaeX-0000QV-7t; Tue, 11 Nov 2003 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJadm-0000P5-6G for simple@optimus.ietf.org; Tue, 11 Nov 2003 10:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06284 for ; Tue, 11 Nov 2003 10:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJadj-0004ow-00 for simple@ietf.org; Tue, 11 Nov 2003 10:41:11 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJadi-0004os-00 for simple@ietf.org; Tue, 11 Nov 2003 10:41:10 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Nov 2003 07:47:09 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABFeaw5001672; Tue, 11 Nov 2003 07:40:37 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-36.cisco.com [10.86.242.36]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADW93200; Tue, 11 Nov 2003 10:40:35 -0500 (EST) Message-ID: <3FB102F2.8050405@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 10:40:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that retransmission over the same connection is useless and shouldn't be attempted. The issue is retransmission of messages pending on the old session when switching to a replacement session. That situation can arise if for instance a relay crashes. In that case the endpoint may well recover by establishing a new session and retransmitting any messages not confirmed on the old one. Of course Hisham is right that it is possible to leave the decision to retransmit to the user of the application. This has a couple of problems: - the end user presumably doesn't have access to tools for suppressing duplicates. So in cases where the old message had been process but the response not delivered this will result in a duplicate message. This can be mitigated somewhat by clarifying conversation between the users at the two ends. - automata at one end or the other will be further limited. They are likely to be less tolerant of problems and less able to mitigate the problems via informal communication. Paul Paul Ben Campbell wrote: > In spite of the fact I keep letting myself get trapped into talking > about retransmitting, I think I agree. If one attempt fails, it seems > highly unlikely another attempt will suddenly succeed. > > hisham.khartabil@nokia.com wrote: > >> Again I ask: why is there a need for retransmission? As I said >> earlier, if a message fails (timeout or 5xx), the end user gets >> presented with this error and it is up to him/her to send it again. >> >> If it was a long message and a timeout has occurred, then only the >> user can decide to send it again (again I'm pointing out that long >> messages can wrongly time out) >> >> /Hisham >> >> >>> -----Original Message----- >>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, November 11, 2003 12:27 AM >>> To: Ben Campbell >>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>> simple@ietf.org >>> Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>> >>> >>> Its true that within a given session it should be sufficient to >>> distinguish between the currently pending messages. So TR-IDs for >>> acknowledged messages could be recycled. >>> >>> OTOH, without some tweaks that makes the problem of failing over to >>> another session harder. >>> >>> This could perhaps be handled by making a two-part TR-ID: >>> .. So when a session is established for the first >>> time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>> fail over to a new session, then ids for new messages are 2.1, 2.2, >>> ..., but retransmissions of old ones would still carry their original >>> TR-ID. >>> >>> A recipient that supports duplicate suppression would need to >>> remember the ids of messages processed until certain the response had >>> been received by the sender. This could be handled a number of >>> different ways: >>> - reuse of a TR-ID in the *same* session isn't a retransmission. It >>> redefines what message it applies to. >>> - if a request is sent in the other direction, any responses sent >>> prior to it can be inferred to have been received, so the messages >>> corresponding to those responses will no longer be eligible for >>> retransmission. >>> - the timeout interval for messages puts an upper bound on how >>> long one needs to be prepared to deal with retransmissions of >>> a message. >>> >>> Paul >>> >>> Ben Campbell wrote: >>> >>>> Aki Niemi wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> At this point I'm really confused about the true meaning for TR-ID. >>>>> >>>>> The current draft reads to me that the TR-ID should be >>>> >>> >>> unique within a >>> >>>>> session, but there still isn't any duplicate suppression on the >>>>> recipient side. If this is the case, I don't even see why >>>> >>> >>> TR-ID needs >>> >>>>> to be unique within a session. It would seem enough for >>>> >>> >>> the sender not >>> >>>>> to have TR-ID collisions occur within the set of *pending* >>>> >>> >>> requests. >>> >>>>> in other words, the TR-ID is opaque to the recipient - >>>> >>> >>> whatever the 5 >>> >>>>> request had is used in the response. >>>> >>>> >>>> >>>> The real requirement for the current usage is exactly as >>> >>> >>> you say, that >>> >>>> is, no collisions within the set of pending requests. >>> >>> >>> Making them unique >>> >>>> inside a session simply seemed the easiest way to enforce this. >>>> >>>> >>>>> Having said that, I think TR-ID is not working to its full >>>> >>> >>> potential, >>> >>>>> and thus I have a new proposal. >>>>> >>>>> Let's make TR-ID a simple counter. Each session starts >>>> >>> >>> from zero, and >>> >>>>> each new message increments this counter. We can come up with a >>>>> reasonable resolution for this counter; x seems as good a value as >>>>> any. When the counter hits x, it is reset to zero. >>>>> The good thing is that we get duplicate detection without the >>>>> recipient having to remember all used TR-IDs within a >>>> >>> >>> session, but it >>> >>>>> suffices to maintain this unidirectional counter on each end. >>>>> >>>>> Whatever the resolution will be, it seems a reasonable >>>> >>> >>> limitation to >>> >>>>> say that a sender can only have x pending requests at a time. >>>> >>>> >>>> >>>> This is interesting. We originally avoided this approach due to >>>> potential problems with shared connections, etc. These >>> >>> >>> problems may all >>> >>>> be gone with the current version. One potential problem >>> >>> >>> comes to mind >>> >>>> is, if TR-ID 2 times out _and_ was never presented to the >>> >>> >>> recipient, >>> >>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >>> >>> >>> falsely be >>> >>>> treated as a duplicate. Now, I am not sure this can really happen >>>> assuming TCP connections all the way. If the receiving peer is >>>> overloaded, but recovers well enough to process TR-ID 3, >>> >>> >>> then TR-ID 2 >>> >>>> will most likely get processed first anyway, wouldn't it? >>>> >>>> Does anyone recall a problem with requiring ordered, >>> >>> >>> contiguous TR-ID >>> >>>> values, and allowing the receiving peer to notice >>> >>> >>> discrepancies, that is >>> >>>> still relevant? >>>> >>>> >>>> >>>>> Cheers, >>>>> Aki >>>>> >>>>> ext Ben Campbell wrote: >>>>> >>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>> >>>>>>> I'm not certain a time period is really necessary. I >>>>>> >>> >>> think this can >>> >>>>>>> be local option. >>>>>>> >>>>>>> Even uniqueness across streams isn't *required*, though >>>>>> >>> >>> it would be >>> >>>>>>> helpful. Instead, we can simply introduce an error >>>>>> >>> >>> response to be >>> >>>>>>> used when a duplicate is detected and supressed. If it >>>>>> >>> >>> was supressed >>> >>>>>>> in error because the sender duplicated a TR-ID from >>>>>> >>> >>> another stream, >>> >>>>>>> the sender would then know to recover. >>>>>>> >>>>>>> But I agree that some further clarification on TR-ID uniqueness >>>>>>> could be helpful. >>>>>>> >>>>>> >>>>>> If TR-ID is not required to be unique across sessions, >>>>> >>> >>> and you allow >>> >>>>>> clients to attempt to find duplicate messages using TR-ID across >>>>>> sessions, then you introduce the possibility of false detection >>>>>> caused by TR-ID collisions. This seems bad to me. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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-admin@ietf.org Tue Nov 11 10:46:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06469; Tue, 11 Nov 2003 10:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJajQ-0004v7-00; Tue, 11 Nov 2003 10:47:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJajQ-0004v4-00; Tue, 11 Nov 2003 10:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajN-0000ad-QD; Tue, 11 Nov 2003 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajI-0000Zm-55 for simple@optimus.ietf.org; Tue, 11 Nov 2003 10:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Tue, 11 Nov 2003 10:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJajF-0004uy-00 for simple@ietf.org; Tue, 11 Nov 2003 10:46:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJajE-0004uv-00 for simple@ietf.org; Tue, 11 Nov 2003 10:46:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABFkUIc052512; Tue, 11 Nov 2003 09:46:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB10453.3000902@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 09:46:27 -0600 Content-Transfer-Encoding: 7bit Adam Roach wrote: > hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: > > >>text/plain does not tell you there is a file attached. I >>believe it has its own mime type. > > > Errmm... no. The mime type doesn't indicate anything about whether > the content is supposed to be rendered to the user or saved to a > file. What you're thinking of is Content-Disposition. > > http://www.ietf.org/rfc/rfc2183.txt > > So, if you wanted to hint that a text/plain payload should be saved > instead of rendered, I would submit that adding a Content-Disposition > header to MSRP would achieve the effect you want. Use of content-disposition is interesting, for the reason you mention, that is to suggest how to render a particular message. I am certainly open to allowing it in an MSRP message. But to head off any proposal of saying we should use this to label the purpose of an entire _session, I think if we were going to go so far as to carry content-disposition in the SDP, we could come up with something both syntactically simpler and better fitting the semantic. > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 10:47:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06514 for ; Tue, 11 Nov 2003 10:47:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajV-0000h0-3X for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 10:47:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFl9CJ002656 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 10:47:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajU-0000eu-NL for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 10:47:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06469; Tue, 11 Nov 2003 10:46:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJajQ-0004v7-00; Tue, 11 Nov 2003 10:47:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJajQ-0004v4-00; Tue, 11 Nov 2003 10:47:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajN-0000ad-QD; Tue, 11 Nov 2003 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJajI-0000Zm-55 for simple@optimus.ietf.org; Tue, 11 Nov 2003 10:46:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06464 for ; Tue, 11 Nov 2003 10:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJajF-0004uy-00 for simple@ietf.org; Tue, 11 Nov 2003 10:46:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJajE-0004uv-00 for simple@ietf.org; Tue, 11 Nov 2003 10:46:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABFkUIc052512; Tue, 11 Nov 2003 09:46:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB10453.3000902@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 09:46:27 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: > > >>text/plain does not tell you there is a file attached. I >>believe it has its own mime type. > > > Errmm... no. The mime type doesn't indicate anything about whether > the content is supposed to be rendered to the user or saved to a > file. What you're thinking of is Content-Disposition. > > http://www.ietf.org/rfc/rfc2183.txt > > So, if you wanted to hint that a text/plain payload should be saved > instead of rendered, I would submit that adding a Content-Disposition > header to MSRP would achieve the effect you want. Use of content-disposition is interesting, for the reason you mention, that is to suggest how to render a particular message. I am certainly open to allowing it in an MSRP message. But to head off any proposal of saying we should use this to label the purpose of an entire _session, I think if we were going to go so far as to carry content-disposition in the SDP, we could come up with something both syntactically simpler and better fitting the semantic. > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 10:58:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07056; Tue, 11 Nov 2003 10:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJav6-00054B-00; Tue, 11 Nov 2003 10:59:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJav6-000548-00; Tue, 11 Nov 2003 10:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJauz-0001X7-I3; Tue, 11 Nov 2003 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaua-0001UB-Mv for simple@optimus.ietf.org; Tue, 11 Nov 2003 10:58:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07034 for ; Tue, 11 Nov 2003 10:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJauY-00053o-00 for simple@ietf.org; Tue, 11 Nov 2003 10:58:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJauW-00053l-00 for simple@ietf.org; Tue, 11 Nov 2003 10:58:33 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABFw3Ic053453; Tue, 11 Nov 2003 09:58:15 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB10709.5050403@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> In-Reply-To: <3FB102F2.8050405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 09:58:01 -0600 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I agree that retransmission over the same connection is useless and > shouldn't be attempted. The issue is retransmission of messages pending > on the old session when switching to a replacement session. That > situation can arise if for instance a relay crashes. In that case the > endpoint may well recover by establishing a new session and > retransmitting any messages not confirmed on the old one. OK, so to clarify the bounderies of this discussion, we do not think that retransmission within a particular session is useful. This implies that duplicate suppression _within_ a session is not particularly interesting for its on sake. Do the active participants in this conversation agree with this point? We _are_ however, concerned about how an implementation might _resume_ a session that has died for whatever reason. By _resume_, I mean create a new (and unrelated at the protocol level) session that continues the conversation. In this case, an implementation might choose to re-send content for which receiption on the previous session could not be confirmed. If this occurs, it may be interesting to have a cross-session duplicate suppression mechanism. There is still open discussion on whether this is needed at all, and if so, should it be required or optional. We pretty much agree that if we were to do something like this, it would involve TR-ID, but there is still open discussion on how strong of requirements we would need for uniqueness, and remembering past values. Do the active participants in this conversation agree that this is the current state of the controversy? > > Of course Hisham is right that it is possible to leave the decision to > retransmit to the user of the application. This has a couple of problems: > - the end user presumably doesn't have access to tools for suppressing > duplicates. So in cases where the old message had been process but the > response not delivered this will result in a duplicate message. This can > be mitigated somewhat by clarifying conversation between the users at > the two ends. > > - automata at one end or the other will be further limited. They are > likely to be less tolerant of problems and less able to mitigate the > problems via informal communication. > I would hope that automata would be designed so that duplicates cause no harm--but I guess it is hard to guarantee that. I must also point out that our primary use case is delivering messages to humans. While we do not prohibit automata, we have generally not included requirements that are specific to automata processing. > Paul > > Paul > > Ben Campbell wrote: > >> In spite of the fact I keep letting myself get trapped into talking >> about retransmitting, I think I agree. If one attempt fails, it seems >> highly unlikely another attempt will suddenly succeed. >> >> hisham.khartabil@nokia.com wrote: >> >>> Again I ask: why is there a need for retransmission? As I said >>> earlier, if a message fails (timeout or 5xx), the end user gets >>> presented with this error and it is up to him/her to send it again. >>> >>> If it was a long message and a timeout has occurred, then only the >>> user can decide to send it again (again I'm pointing out that long >>> messages can wrongly time out) >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, November 11, 2003 12:27 AM >>>> To: Ben Campbell >>>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>>> simple@ietf.org >>>> Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>>> >>>> >>>> Its true that within a given session it should be sufficient to >>>> distinguish between the currently pending messages. So TR-IDs for >>>> acknowledged messages could be recycled. >>>> >>>> OTOH, without some tweaks that makes the problem of failing over to >>>> another session harder. >>>> >>>> This could perhaps be handled by making a two-part TR-ID: >>>> .. So when a session is established for the first >>>> time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>>> fail over to a new session, then ids for new messages are 2.1, 2.2, >>>> ..., but retransmissions of old ones would still carry their >>>> original TR-ID. >>>> >>>> A recipient that supports duplicate suppression would need to >>>> remember the ids of messages processed until certain the response >>>> had been received by the sender. This could be handled a number of >>>> different ways: >>>> - reuse of a TR-ID in the *same* session isn't a retransmission. It >>>> redefines what message it applies to. >>>> - if a request is sent in the other direction, any responses sent >>>> prior to it can be inferred to have been received, so the messages >>>> corresponding to those responses will no longer be eligible for >>>> retransmission. >>>> - the timeout interval for messages puts an upper bound on how >>>> long one needs to be prepared to deal with retransmissions of >>>> a message. >>>> >>>> Paul >>>> >>>> Ben Campbell wrote: >>>> >>>>> Aki Niemi wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> At this point I'm really confused about the true meaning for TR-ID. >>>>>> >>>>>> The current draft reads to me that the TR-ID should be >>>>> >>>>> >>>> >>>> unique within a >>>> >>>>>> session, but there still isn't any duplicate suppression on the >>>>>> recipient side. If this is the case, I don't even see why >>>>> >>>>> >>>> >>>> TR-ID needs >>>> >>>>>> to be unique within a session. It would seem enough for >>>>> >>>>> >>>> >>>> the sender not >>>> >>>>>> to have TR-ID collisions occur within the set of *pending* >>>>> >>>>> >>>> >>>> requests. >>>> >>>>>> in other words, the TR-ID is opaque to the recipient - >>>>> >>>>> >>>> >>>> whatever the 5 >>>> >>>>>> request had is used in the response. >>>>> >>>>> >>>>> >>>>> >>>>> The real requirement for the current usage is exactly as >>>> >>>> >>>> >>>> you say, that >>>> >>>>> is, no collisions within the set of pending requests. >>>> >>>> >>>> >>>> Making them unique >>>> >>>>> inside a session simply seemed the easiest way to enforce this. >>>>> >>>>> >>>>>> Having said that, I think TR-ID is not working to its full >>>>> >>>>> >>>> >>>> potential, >>>> >>>>>> and thus I have a new proposal. >>>>>> >>>>>> Let's make TR-ID a simple counter. Each session starts >>>>> >>>>> >>>> >>>> from zero, and >>>> >>>>>> each new message increments this counter. We can come up with a >>>>>> reasonable resolution for this counter; x seems as good a value as >>>>>> any. When the counter hits x, it is reset to zero. >>>>>> The good thing is that we get duplicate detection without the >>>>>> recipient having to remember all used TR-IDs within a >>>>> >>>>> >>>> >>>> session, but it >>>> >>>>>> suffices to maintain this unidirectional counter on each end. >>>>>> >>>>>> Whatever the resolution will be, it seems a reasonable >>>>> >>>>> >>>> >>>> limitation to >>>> >>>>>> say that a sender can only have x pending requests at a time. >>>>> >>>>> >>>>> >>>>> >>>>> This is interesting. We originally avoided this approach due to >>>>> potential problems with shared connections, etc. These >>>> >>>> >>>> >>>> problems may all >>>> >>>>> be gone with the current version. One potential problem >>>> >>>> >>>> >>>> comes to mind >>>> >>>>> is, if TR-ID 2 times out _and_ was never presented to the >>>> >>>> >>>> >>>> recipient, >>>> >>>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >>>> >>>> >>>> >>>> falsely be >>>> >>>>> treated as a duplicate. Now, I am not sure this can really happen >>>>> assuming TCP connections all the way. If the receiving peer is >>>>> overloaded, but recovers well enough to process TR-ID 3, >>>> >>>> >>>> >>>> then TR-ID 2 >>>> >>>>> will most likely get processed first anyway, wouldn't it? >>>>> >>>>> Does anyone recall a problem with requiring ordered, >>>> >>>> >>>> >>>> contiguous TR-ID >>>> >>>>> values, and allowing the receiving peer to notice >>>> >>>> >>>> >>>> discrepancies, that is >>>> >>>>> still relevant? >>>>> >>>>> >>>>> >>>>>> Cheers, >>>>>> Aki >>>>>> >>>>>> ext Ben Campbell wrote: >>>>>> >>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>> >>>>>>>> I'm not certain a time period is really necessary. I >>>>>>> >>>>>>> >>>> >>>> think this can >>>> >>>>>>>> be local option. >>>>>>>> >>>>>>>> Even uniqueness across streams isn't *required*, though >>>>>>> >>>>>>> >>>> >>>> it would be >>>> >>>>>>>> helpful. Instead, we can simply introduce an error >>>>>>> >>>>>>> >>>> >>>> response to be >>>> >>>>>>>> used when a duplicate is detected and supressed. If it >>>>>>> >>>>>>> >>>> >>>> was supressed >>>> >>>>>>>> in error because the sender duplicated a TR-ID from >>>>>>> >>>>>>> >>>> >>>> another stream, >>>> >>>>>>>> the sender would then know to recover. >>>>>>>> >>>>>>>> But I agree that some further clarification on TR-ID uniqueness >>>>>>>> could be helpful. >>>>>>>> >>>>>>> >>>>>>> If TR-ID is not required to be unique across sessions, >>>>>> >>>>>> >>>> >>>> and you allow >>>> >>>>>>> clients to attempt to find duplicate messages using TR-ID across >>>>>>> sessions, then you introduce the possibility of false detection >>>>>>> caused by TR-ID collisions. This seems bad to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 exim@www1.ietf.org Tue Nov 11 10:59:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07102 for ; Tue, 11 Nov 2003 10:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJavB-0001ZQ-8K for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 10:59:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABFxDFd006029 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 10:59:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJavB-0001ZA-0V for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 10:59:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07056; Tue, 11 Nov 2003 10:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJav6-00054B-00; Tue, 11 Nov 2003 10:59:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJav6-000548-00; Tue, 11 Nov 2003 10:59:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJauz-0001X7-I3; Tue, 11 Nov 2003 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJaua-0001UB-Mv for simple@optimus.ietf.org; Tue, 11 Nov 2003 10:58:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07034 for ; Tue, 11 Nov 2003 10:58:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJauY-00053o-00 for simple@ietf.org; Tue, 11 Nov 2003 10:58:34 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJauW-00053l-00 for simple@ietf.org; Tue, 11 Nov 2003 10:58:33 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABFw3Ic053453; Tue, 11 Nov 2003 09:58:15 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB10709.5050403@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> In-Reply-To: <3FB102F2.8050405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 09:58:01 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I agree that retransmission over the same connection is useless and > shouldn't be attempted. The issue is retransmission of messages pending > on the old session when switching to a replacement session. That > situation can arise if for instance a relay crashes. In that case the > endpoint may well recover by establishing a new session and > retransmitting any messages not confirmed on the old one. OK, so to clarify the bounderies of this discussion, we do not think that retransmission within a particular session is useful. This implies that duplicate suppression _within_ a session is not particularly interesting for its on sake. Do the active participants in this conversation agree with this point? We _are_ however, concerned about how an implementation might _resume_ a session that has died for whatever reason. By _resume_, I mean create a new (and unrelated at the protocol level) session that continues the conversation. In this case, an implementation might choose to re-send content for which receiption on the previous session could not be confirmed. If this occurs, it may be interesting to have a cross-session duplicate suppression mechanism. There is still open discussion on whether this is needed at all, and if so, should it be required or optional. We pretty much agree that if we were to do something like this, it would involve TR-ID, but there is still open discussion on how strong of requirements we would need for uniqueness, and remembering past values. Do the active participants in this conversation agree that this is the current state of the controversy? > > Of course Hisham is right that it is possible to leave the decision to > retransmit to the user of the application. This has a couple of problems: > - the end user presumably doesn't have access to tools for suppressing > duplicates. So in cases where the old message had been process but the > response not delivered this will result in a duplicate message. This can > be mitigated somewhat by clarifying conversation between the users at > the two ends. > > - automata at one end or the other will be further limited. They are > likely to be less tolerant of problems and less able to mitigate the > problems via informal communication. > I would hope that automata would be designed so that duplicates cause no harm--but I guess it is hard to guarantee that. I must also point out that our primary use case is delivering messages to humans. While we do not prohibit automata, we have generally not included requirements that are specific to automata processing. > Paul > > Paul > > Ben Campbell wrote: > >> In spite of the fact I keep letting myself get trapped into talking >> about retransmitting, I think I agree. If one attempt fails, it seems >> highly unlikely another attempt will suddenly succeed. >> >> hisham.khartabil@nokia.com wrote: >> >>> Again I ask: why is there a need for retransmission? As I said >>> earlier, if a message fails (timeout or 5xx), the end user gets >>> presented with this error and it is up to him/her to send it again. >>> >>> If it was a long message and a timeout has occurred, then only the >>> user can decide to send it again (again I'm pointing out that long >>> messages can wrongly time out) >>> >>> /Hisham >>> >>> >>>> -----Original Message----- >>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, November 11, 2003 12:27 AM >>>> To: Ben Campbell >>>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>>> simple@ietf.org >>>> Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>>> >>>> >>>> Its true that within a given session it should be sufficient to >>>> distinguish between the currently pending messages. So TR-IDs for >>>> acknowledged messages could be recycled. >>>> >>>> OTOH, without some tweaks that makes the problem of failing over to >>>> another session harder. >>>> >>>> This could perhaps be handled by making a two-part TR-ID: >>>> .. So when a session is established for the first >>>> time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>>> fail over to a new session, then ids for new messages are 2.1, 2.2, >>>> ..., but retransmissions of old ones would still carry their >>>> original TR-ID. >>>> >>>> A recipient that supports duplicate suppression would need to >>>> remember the ids of messages processed until certain the response >>>> had been received by the sender. This could be handled a number of >>>> different ways: >>>> - reuse of a TR-ID in the *same* session isn't a retransmission. It >>>> redefines what message it applies to. >>>> - if a request is sent in the other direction, any responses sent >>>> prior to it can be inferred to have been received, so the messages >>>> corresponding to those responses will no longer be eligible for >>>> retransmission. >>>> - the timeout interval for messages puts an upper bound on how >>>> long one needs to be prepared to deal with retransmissions of >>>> a message. >>>> >>>> Paul >>>> >>>> Ben Campbell wrote: >>>> >>>>> Aki Niemi wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> At this point I'm really confused about the true meaning for TR-ID. >>>>>> >>>>>> The current draft reads to me that the TR-ID should be >>>>> >>>>> >>>> >>>> unique within a >>>> >>>>>> session, but there still isn't any duplicate suppression on the >>>>>> recipient side. If this is the case, I don't even see why >>>>> >>>>> >>>> >>>> TR-ID needs >>>> >>>>>> to be unique within a session. It would seem enough for >>>>> >>>>> >>>> >>>> the sender not >>>> >>>>>> to have TR-ID collisions occur within the set of *pending* >>>>> >>>>> >>>> >>>> requests. >>>> >>>>>> in other words, the TR-ID is opaque to the recipient - >>>>> >>>>> >>>> >>>> whatever the 5 >>>> >>>>>> request had is used in the response. >>>>> >>>>> >>>>> >>>>> >>>>> The real requirement for the current usage is exactly as >>>> >>>> >>>> >>>> you say, that >>>> >>>>> is, no collisions within the set of pending requests. >>>> >>>> >>>> >>>> Making them unique >>>> >>>>> inside a session simply seemed the easiest way to enforce this. >>>>> >>>>> >>>>>> Having said that, I think TR-ID is not working to its full >>>>> >>>>> >>>> >>>> potential, >>>> >>>>>> and thus I have a new proposal. >>>>>> >>>>>> Let's make TR-ID a simple counter. Each session starts >>>>> >>>>> >>>> >>>> from zero, and >>>> >>>>>> each new message increments this counter. We can come up with a >>>>>> reasonable resolution for this counter; x seems as good a value as >>>>>> any. When the counter hits x, it is reset to zero. >>>>>> The good thing is that we get duplicate detection without the >>>>>> recipient having to remember all used TR-IDs within a >>>>> >>>>> >>>> >>>> session, but it >>>> >>>>>> suffices to maintain this unidirectional counter on each end. >>>>>> >>>>>> Whatever the resolution will be, it seems a reasonable >>>>> >>>>> >>>> >>>> limitation to >>>> >>>>>> say that a sender can only have x pending requests at a time. >>>>> >>>>> >>>>> >>>>> >>>>> This is interesting. We originally avoided this approach due to >>>>> potential problems with shared connections, etc. These >>>> >>>> >>>> >>>> problems may all >>>> >>>>> be gone with the current version. One potential problem >>>> >>>> >>>> >>>> comes to mind >>>> >>>>> is, if TR-ID 2 times out _and_ was never presented to the >>>> >>>> >>>> >>>> recipient, >>>> >>>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >>>> >>>> >>>> >>>> falsely be >>>> >>>>> treated as a duplicate. Now, I am not sure this can really happen >>>>> assuming TCP connections all the way. If the receiving peer is >>>>> overloaded, but recovers well enough to process TR-ID 3, >>>> >>>> >>>> >>>> then TR-ID 2 >>>> >>>>> will most likely get processed first anyway, wouldn't it? >>>>> >>>>> Does anyone recall a problem with requiring ordered, >>>> >>>> >>>> >>>> contiguous TR-ID >>>> >>>>> values, and allowing the receiving peer to notice >>>> >>>> >>>> >>>> discrepancies, that is >>>> >>>>> still relevant? >>>>> >>>>> >>>>> >>>>>> Cheers, >>>>>> Aki >>>>>> >>>>>> ext Ben Campbell wrote: >>>>>> >>>>>> >>>>>>> Paul Kyzivat wrote: >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>> >>>>>>>> I'm not certain a time period is really necessary. I >>>>>>> >>>>>>> >>>> >>>> think this can >>>> >>>>>>>> be local option. >>>>>>>> >>>>>>>> Even uniqueness across streams isn't *required*, though >>>>>>> >>>>>>> >>>> >>>> it would be >>>> >>>>>>>> helpful. Instead, we can simply introduce an error >>>>>>> >>>>>>> >>>> >>>> response to be >>>> >>>>>>>> used when a duplicate is detected and supressed. If it >>>>>>> >>>>>>> >>>> >>>> was supressed >>>> >>>>>>>> in error because the sender duplicated a TR-ID from >>>>>>> >>>>>>> >>>> >>>> another stream, >>>> >>>>>>>> the sender would then know to recover. >>>>>>>> >>>>>>>> But I agree that some further clarification on TR-ID uniqueness >>>>>>>> could be helpful. >>>>>>>> >>>>>>> >>>>>>> If TR-ID is not required to be unique across sessions, >>>>>> >>>>>> >>>> >>>> and you allow >>>> >>>>>>> clients to attempt to find duplicate messages using TR-ID across >>>>>>> sessions, then you introduce the possibility of false detection >>>>>>> caused by TR-ID collisions. This seems bad to me. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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-admin@ietf.org Tue Nov 11 11:07:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07469; Tue, 11 Nov 2003 11:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJb3l-0005B6-00; Tue, 11 Nov 2003 11:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJb3l-0005B3-00; Tue, 11 Nov 2003 11:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb3h-0002cp-RX; Tue, 11 Nov 2003 11:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb2r-0002OD-CB for simple@optimus.ietf.org; Tue, 11 Nov 2003 11:07:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07445 for ; Tue, 11 Nov 2003 11:06:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJb2o-0005Aq-00 for simple@ietf.org; Tue, 11 Nov 2003 11:07:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJb2n-0005Al-00 for simple@ietf.org; Tue, 11 Nov 2003 11:07:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABG73B19337 for ; Tue, 11 Nov 2003 18:07:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 18:07:03 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 18:07:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973B2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOobKw1jva1mkNdQLO0h8Oh8hUwRgAAJfGQ To: , Cc: , X-OriginalArrivalTime: 11 Nov 2003 16:07:02.0656 (UTC) FILETIME=[D8137000:01C3A86D] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 18:07:02 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, November 11, 2003 5:58 PM > To: Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > Paul Kyzivat wrote: > > I agree that retransmission over the same connection is useless and=20 > > shouldn't be attempted. The issue is retransmission of=20 > messages pending=20 > > on the old session when switching to a replacement session. That=20 > > situation can arise if for instance a relay crashes. In=20 > that case the=20 > > endpoint may well recover by establishing a new session and=20 > > retransmitting any messages not confirmed on the old one. >=20 > OK, so to clarify the bounderies of this discussion, we do not think=20 > that retransmission within a particular session is useful.=20 > This implies=20 > that duplicate suppression _within_ a session is not particularly=20 > interesting for its on sake. Do the active participants in this=20 > conversation agree with this point? Yes. >=20 > We _are_ however, concerned about how an implementation might=20 > _resume_ a=20 > session that has died for whatever reason. By _resume_, I=20 > mean create=20 > a new (and unrelated at the protocol level) session that=20 > continues the=20 > conversation. In this case, an implementation might choose to re-send=20 > content for which receiption on the previous session could not be=20 > confirmed. If this occurs, it may be interesting to have a=20 > cross-session=20 > duplicate suppression mechanism. There is still open discussion on=20 > whether this is needed at all, and if so, should it be required or=20 > optional. We pretty much agree that if we were to do something like=20 > this, it would involve TR-ID, but there is still open=20 > discussion on how=20 > strong of requirements we would need for uniqueness, and remembering=20 > past values. Do the active participants in this conversation=20 > agree that=20 > this is the current state of the controversy? Retransmission of any kind is harmful if long messages are being sent. = Ignoring the issue of automata, I still vote for not doing transmission = of any kind (over the same or different sessions). /Hisham >=20 > >=20 > > Of course Hisham is right that it is possible to leave the=20 > decision to=20 > > retransmit to the user of the application. This has a=20 > couple of problems: > > - the end user presumably doesn't have access to tools for=20 > suppressing=20 > > duplicates. So in cases where the old message had been=20 > process but the=20 > > response not delivered this will result in a duplicate=20 > message. This can=20 > > be mitigated somewhat by clarifying conversation between=20 > the users at=20 > > the two ends. > >=20 > > - automata at one end or the other will be further limited.=20 > They are=20 > > likely to be less tolerant of problems and less able to=20 > mitigate the=20 > > problems via informal communication. > >=20 >=20 > I would hope that automata would be designed so that=20 > duplicates cause no=20 > harm--but I guess it is hard to guarantee that. I must also point out=20 > that our primary use case is delivering messages to humans.=20 > While we do=20 > not prohibit automata, we have generally not included=20 > requirements that=20 > are specific to automata processing. >=20 > > Paul > >=20 > > Paul > >=20 > > Ben Campbell wrote: > >=20 > >> In spite of the fact I keep letting myself get trapped=20 > into talking=20 > >> about retransmitting, I think I agree. If one attempt=20 > fails, it seems=20 > >> highly unlikely another attempt will suddenly succeed. > >> > >> hisham.khartabil@nokia.com wrote: > >> > >>> Again I ask: why is there a need for retransmission? As I said=20 > >>> earlier, if a message fails (timeout or 5xx), the end user gets=20 > >>> presented with this error and it is up to him/her to send=20 > it again. > >>> > >>> If it was a long message and a timeout has occurred, then=20 > only the=20 > >>> user can decide to send it again (again I'm pointing out=20 > that long=20 > >>> messages can wrongly time out) > >>> > >>> /Hisham > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Tuesday, November 11, 2003 12:27 AM > >>>> To: Ben Campbell > >>>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham=20 > (NMP-MSW/Helsinki); > >>>> simple@ietf.org > >>>> Subject: Re: [Simple] Comments on message-sessions-02 -=20 > message retry > >>>> > >>>> > >>>> Its true that within a given session it should be sufficient to=20 > >>>> distinguish between the currently pending messages. So=20 > TR-IDs for=20 > >>>> acknowledged messages could be recycled. > >>>> > >>>> OTOH, without some tweaks that makes the problem of=20 > failing over to=20 > >>>> another session harder. > >>>> > >>>> This could perhaps be handled by making a two-part TR-ID:=20 > >>>> .. So when a session is established for=20 > the first=20 > >>>> time, ids are of the form 1.1, 1.2, ... Then, if it is=20 > necessary to=20 > >>>> fail over to a new session, then ids for new messages=20 > are 2.1, 2.2,=20 > >>>> ..., but retransmissions of old ones would still carry their=20 > >>>> original TR-ID. > >>>> > >>>> A recipient that supports duplicate suppression would need to=20 > >>>> remember the ids of messages processed until certain the=20 > response=20 > >>>> had been received by the sender. This could be handled a=20 > number of=20 > >>>> different ways: > >>>> - reuse of a TR-ID in the *same* session isn't a=20 > retransmission. It > >>>> redefines what message it applies to. > >>>> - if a request is sent in the other direction, any responses sent > >>>> prior to it can be inferred to have been received, so=20 > the messages > >>>> corresponding to those responses will no longer be eligible for > >>>> retransmission. > >>>> - the timeout interval for messages puts an upper bound on how > >>>> long one needs to be prepared to deal with retransmissions of > >>>> a message. > >>>> > >>>> Paul > >>>> > >>>> Ben Campbell wrote: > >>>> > >>>>> Aki Niemi wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> At this point I'm really confused about the true=20 > meaning for TR-ID. > >>>>>> > >>>>>> The current draft reads to me that the TR-ID should be=20 > >>>>> > >>>>> > >>>> > >>>> unique within a > >>>> > >>>>>> session, but there still isn't any duplicate=20 > suppression on the=20 > >>>>>> recipient side. If this is the case, I don't even see why=20 > >>>>> > >>>>> > >>>> > >>>> TR-ID needs > >>>> > >>>>>> to be unique within a session. It would seem enough for=20 > >>>>> > >>>>> > >>>> > >>>> the sender not > >>>> > >>>>>> to have TR-ID collisions occur within the set of *pending*=20 > >>>>> > >>>>> > >>>> > >>>> requests. > >>>> > >>>>>> in other words, the TR-ID is opaque to the recipient -=20 > >>>>> > >>>>> > >>>> > >>>> whatever the 5 > >>>> > >>>>>> request had is used in the response. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The real requirement for the current usage is exactly as=20 > >>>> > >>>> > >>>> > >>>> you say, that > >>>> > >>>>> is, no collisions within the set of pending requests.=20 > >>>> > >>>> > >>>> > >>>> Making them unique > >>>> > >>>>> inside a session simply seemed the easiest way to enforce this. > >>>>> > >>>>> > >>>>>> Having said that, I think TR-ID is not working to its full=20 > >>>>> > >>>>> > >>>> > >>>> potential, > >>>> > >>>>>> and thus I have a new proposal. > >>>>>> > >>>>>> Let's make TR-ID a simple counter. Each session starts=20 > >>>>> > >>>>> > >>>> > >>>> from zero, and > >>>> > >>>>>> each new message increments this counter. We can come=20 > up with a=20 > >>>>>> reasonable resolution for this counter; x seems as=20 > good a value as=20 > >>>>>> any. When the counter hits x, it is reset to zero. > >>>>>> The good thing is that we get duplicate detection without the=20 > >>>>>> recipient having to remember all used TR-IDs within a=20 > >>>>> > >>>>> > >>>> > >>>> session, but it > >>>> > >>>>>> suffices to maintain this unidirectional counter on each end. > >>>>>> > >>>>>> Whatever the resolution will be, it seems a reasonable=20 > >>>>> > >>>>> > >>>> > >>>> limitation to > >>>> > >>>>>> say that a sender can only have x pending requests at a time. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> This is interesting. We originally avoided this approach due to=20 > >>>>> potential problems with shared connections, etc. These=20 > >>>> > >>>> > >>>> > >>>> problems may all > >>>> > >>>>> be gone with the current version. One potential problem=20 > >>>> > >>>> > >>>> > >>>> comes to mind > >>>> > >>>>> is, if TR-ID 2 times out _and_ was never presented to the=20 > >>>> > >>>> > >>>> > >>>> recipient, > >>>> > >>>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may=20 > >>>> > >>>> > >>>> > >>>> falsely be > >>>> > >>>>> treated as a duplicate. Now, I am not sure this can=20 > really happen=20 > >>>>> assuming TCP connections all the way. If the receiving peer is=20 > >>>>> overloaded, but recovers well enough to process TR-ID 3,=20 > >>>> > >>>> > >>>> > >>>> then TR-ID 2 > >>>> > >>>>> will most likely get processed first anyway, wouldn't it? > >>>>> > >>>>> Does anyone recall a problem with requiring ordered,=20 > >>>> > >>>> > >>>> > >>>> contiguous TR-ID > >>>> > >>>>> values, and allowing the receiving peer to notice=20 > >>>> > >>>> > >>>> > >>>> discrepancies, that is > >>>> > >>>>> still relevant? > >>>>> > >>>>> > >>>>> > >>>>>> Cheers, > >>>>>> Aki > >>>>>> > >>>>>> ext Ben Campbell wrote: > >>>>>> > >>>>>> > >>>>>>> Paul Kyzivat wrote: > >>>>>>> > >>>>>>> [...] > >>>>>>> > >>>>>>> > >>>>>>>> I'm not certain a time period is really necessary. I=20 > >>>>>>> > >>>>>>> > >>>> > >>>> think this can > >>>> > >>>>>>>> be local option. > >>>>>>>> > >>>>>>>> Even uniqueness across streams isn't *required*, though=20 > >>>>>>> > >>>>>>> > >>>> > >>>> it would be > >>>> > >>>>>>>> helpful. Instead, we can simply introduce an error=20 > >>>>>>> > >>>>>>> > >>>> > >>>> response to be > >>>> > >>>>>>>> used when a duplicate is detected and supressed. If it=20 > >>>>>>> > >>>>>>> > >>>> > >>>> was supressed > >>>> > >>>>>>>> in error because the sender duplicated a TR-ID from=20 > >>>>>>> > >>>>>>> > >>>> > >>>> another stream, > >>>> > >>>>>>>> the sender would then know to recover. > >>>>>>>> > >>>>>>>> But I agree that some further clarification on TR-ID=20 > uniqueness=20 > >>>>>>>> could be helpful. > >>>>>>>> > >>>>>>> > >>>>>>> If TR-ID is not required to be unique across sessions,=20 > >>>>>> > >>>>>> > >>>> > >>>> and you allow > >>>> > >>>>>>> clients to attempt to find duplicate messages using=20 > TR-ID across=20 > >>>>>>> sessions, then you introduce the possibility of false=20 > detection=20 > >>>>>>> caused by TR-ID collisions. This seems bad to me. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Simple mailing list > >>>>>>> Simple@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >> > >> > >> > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 11:08:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07485 for ; Tue, 11 Nov 2003 11:08:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb3r-0002gK-HI for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 11:08:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABG8BcD010221 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 11:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb3q-0002eQ-2Q for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 11:08:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07469; Tue, 11 Nov 2003 11:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJb3l-0005B6-00; Tue, 11 Nov 2003 11:08:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJb3l-0005B3-00; Tue, 11 Nov 2003 11:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb3h-0002cp-RX; Tue, 11 Nov 2003 11:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJb2r-0002OD-CB for simple@optimus.ietf.org; Tue, 11 Nov 2003 11:07:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07445 for ; Tue, 11 Nov 2003 11:06:55 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJb2o-0005Aq-00 for simple@ietf.org; Tue, 11 Nov 2003 11:07:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJb2n-0005Al-00 for simple@ietf.org; Tue, 11 Nov 2003 11:07:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABG73B19337 for ; Tue, 11 Nov 2003 18:07:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 18:07:03 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 18:07:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973B2@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcOobKw1jva1mkNdQLO0h8Oh8hUwRgAAJfGQ To: , Cc: , X-OriginalArrivalTime: 11 Nov 2003 16:07:02.0656 (UTC) FILETIME=[D8137000:01C3A86D] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 18:07:02 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, November 11, 2003 5:58 PM > To: Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > Paul Kyzivat wrote: > > I agree that retransmission over the same connection is useless and=20 > > shouldn't be attempted. The issue is retransmission of=20 > messages pending=20 > > on the old session when switching to a replacement session. That=20 > > situation can arise if for instance a relay crashes. In=20 > that case the=20 > > endpoint may well recover by establishing a new session and=20 > > retransmitting any messages not confirmed on the old one. >=20 > OK, so to clarify the bounderies of this discussion, we do not think=20 > that retransmission within a particular session is useful.=20 > This implies=20 > that duplicate suppression _within_ a session is not particularly=20 > interesting for its on sake. Do the active participants in this=20 > conversation agree with this point? Yes. >=20 > We _are_ however, concerned about how an implementation might=20 > _resume_ a=20 > session that has died for whatever reason. By _resume_, I=20 > mean create=20 > a new (and unrelated at the protocol level) session that=20 > continues the=20 > conversation. In this case, an implementation might choose to re-send=20 > content for which receiption on the previous session could not be=20 > confirmed. If this occurs, it may be interesting to have a=20 > cross-session=20 > duplicate suppression mechanism. There is still open discussion on=20 > whether this is needed at all, and if so, should it be required or=20 > optional. We pretty much agree that if we were to do something like=20 > this, it would involve TR-ID, but there is still open=20 > discussion on how=20 > strong of requirements we would need for uniqueness, and remembering=20 > past values. Do the active participants in this conversation=20 > agree that=20 > this is the current state of the controversy? Retransmission of any kind is harmful if long messages are being sent. = Ignoring the issue of automata, I still vote for not doing transmission = of any kind (over the same or different sessions). /Hisham >=20 > >=20 > > Of course Hisham is right that it is possible to leave the=20 > decision to=20 > > retransmit to the user of the application. This has a=20 > couple of problems: > > - the end user presumably doesn't have access to tools for=20 > suppressing=20 > > duplicates. So in cases where the old message had been=20 > process but the=20 > > response not delivered this will result in a duplicate=20 > message. This can=20 > > be mitigated somewhat by clarifying conversation between=20 > the users at=20 > > the two ends. > >=20 > > - automata at one end or the other will be further limited.=20 > They are=20 > > likely to be less tolerant of problems and less able to=20 > mitigate the=20 > > problems via informal communication. > >=20 >=20 > I would hope that automata would be designed so that=20 > duplicates cause no=20 > harm--but I guess it is hard to guarantee that. I must also point out=20 > that our primary use case is delivering messages to humans.=20 > While we do=20 > not prohibit automata, we have generally not included=20 > requirements that=20 > are specific to automata processing. >=20 > > Paul > >=20 > > Paul > >=20 > > Ben Campbell wrote: > >=20 > >> In spite of the fact I keep letting myself get trapped=20 > into talking=20 > >> about retransmitting, I think I agree. If one attempt=20 > fails, it seems=20 > >> highly unlikely another attempt will suddenly succeed. > >> > >> hisham.khartabil@nokia.com wrote: > >> > >>> Again I ask: why is there a need for retransmission? As I said=20 > >>> earlier, if a message fails (timeout or 5xx), the end user gets=20 > >>> presented with this error and it is up to him/her to send=20 > it again. > >>> > >>> If it was a long message and a timeout has occurred, then=20 > only the=20 > >>> user can decide to send it again (again I'm pointing out=20 > that long=20 > >>> messages can wrongly time out) > >>> > >>> /Hisham > >>> > >>> > >>>> -----Original Message----- > >>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>> Sent: Tuesday, November 11, 2003 12:27 AM > >>>> To: Ben Campbell > >>>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham=20 > (NMP-MSW/Helsinki); > >>>> simple@ietf.org > >>>> Subject: Re: [Simple] Comments on message-sessions-02 -=20 > message retry > >>>> > >>>> > >>>> Its true that within a given session it should be sufficient to=20 > >>>> distinguish between the currently pending messages. So=20 > TR-IDs for=20 > >>>> acknowledged messages could be recycled. > >>>> > >>>> OTOH, without some tweaks that makes the problem of=20 > failing over to=20 > >>>> another session harder. > >>>> > >>>> This could perhaps be handled by making a two-part TR-ID:=20 > >>>> .. So when a session is established for=20 > the first=20 > >>>> time, ids are of the form 1.1, 1.2, ... Then, if it is=20 > necessary to=20 > >>>> fail over to a new session, then ids for new messages=20 > are 2.1, 2.2,=20 > >>>> ..., but retransmissions of old ones would still carry their=20 > >>>> original TR-ID. > >>>> > >>>> A recipient that supports duplicate suppression would need to=20 > >>>> remember the ids of messages processed until certain the=20 > response=20 > >>>> had been received by the sender. This could be handled a=20 > number of=20 > >>>> different ways: > >>>> - reuse of a TR-ID in the *same* session isn't a=20 > retransmission. It > >>>> redefines what message it applies to. > >>>> - if a request is sent in the other direction, any responses sent > >>>> prior to it can be inferred to have been received, so=20 > the messages > >>>> corresponding to those responses will no longer be eligible for > >>>> retransmission. > >>>> - the timeout interval for messages puts an upper bound on how > >>>> long one needs to be prepared to deal with retransmissions of > >>>> a message. > >>>> > >>>> Paul > >>>> > >>>> Ben Campbell wrote: > >>>> > >>>>> Aki Niemi wrote: > >>>>> > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> At this point I'm really confused about the true=20 > meaning for TR-ID. > >>>>>> > >>>>>> The current draft reads to me that the TR-ID should be=20 > >>>>> > >>>>> > >>>> > >>>> unique within a > >>>> > >>>>>> session, but there still isn't any duplicate=20 > suppression on the=20 > >>>>>> recipient side. If this is the case, I don't even see why=20 > >>>>> > >>>>> > >>>> > >>>> TR-ID needs > >>>> > >>>>>> to be unique within a session. It would seem enough for=20 > >>>>> > >>>>> > >>>> > >>>> the sender not > >>>> > >>>>>> to have TR-ID collisions occur within the set of *pending*=20 > >>>>> > >>>>> > >>>> > >>>> requests. > >>>> > >>>>>> in other words, the TR-ID is opaque to the recipient -=20 > >>>>> > >>>>> > >>>> > >>>> whatever the 5 > >>>> > >>>>>> request had is used in the response. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The real requirement for the current usage is exactly as=20 > >>>> > >>>> > >>>> > >>>> you say, that > >>>> > >>>>> is, no collisions within the set of pending requests.=20 > >>>> > >>>> > >>>> > >>>> Making them unique > >>>> > >>>>> inside a session simply seemed the easiest way to enforce this. > >>>>> > >>>>> > >>>>>> Having said that, I think TR-ID is not working to its full=20 > >>>>> > >>>>> > >>>> > >>>> potential, > >>>> > >>>>>> and thus I have a new proposal. > >>>>>> > >>>>>> Let's make TR-ID a simple counter. Each session starts=20 > >>>>> > >>>>> > >>>> > >>>> from zero, and > >>>> > >>>>>> each new message increments this counter. We can come=20 > up with a=20 > >>>>>> reasonable resolution for this counter; x seems as=20 > good a value as=20 > >>>>>> any. When the counter hits x, it is reset to zero. > >>>>>> The good thing is that we get duplicate detection without the=20 > >>>>>> recipient having to remember all used TR-IDs within a=20 > >>>>> > >>>>> > >>>> > >>>> session, but it > >>>> > >>>>>> suffices to maintain this unidirectional counter on each end. > >>>>>> > >>>>>> Whatever the resolution will be, it seems a reasonable=20 > >>>>> > >>>>> > >>>> > >>>> limitation to > >>>> > >>>>>> say that a sender can only have x pending requests at a time. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> This is interesting. We originally avoided this approach due to=20 > >>>>> potential problems with shared connections, etc. These=20 > >>>> > >>>> > >>>> > >>>> problems may all > >>>> > >>>>> be gone with the current version. One potential problem=20 > >>>> > >>>> > >>>> > >>>> comes to mind > >>>> > >>>>> is, if TR-ID 2 times out _and_ was never presented to the=20 > >>>> > >>>> > >>>> > >>>> recipient, > >>>> > >>>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may=20 > >>>> > >>>> > >>>> > >>>> falsely be > >>>> > >>>>> treated as a duplicate. Now, I am not sure this can=20 > really happen=20 > >>>>> assuming TCP connections all the way. If the receiving peer is=20 > >>>>> overloaded, but recovers well enough to process TR-ID 3,=20 > >>>> > >>>> > >>>> > >>>> then TR-ID 2 > >>>> > >>>>> will most likely get processed first anyway, wouldn't it? > >>>>> > >>>>> Does anyone recall a problem with requiring ordered,=20 > >>>> > >>>> > >>>> > >>>> contiguous TR-ID > >>>> > >>>>> values, and allowing the receiving peer to notice=20 > >>>> > >>>> > >>>> > >>>> discrepancies, that is > >>>> > >>>>> still relevant? > >>>>> > >>>>> > >>>>> > >>>>>> Cheers, > >>>>>> Aki > >>>>>> > >>>>>> ext Ben Campbell wrote: > >>>>>> > >>>>>> > >>>>>>> Paul Kyzivat wrote: > >>>>>>> > >>>>>>> [...] > >>>>>>> > >>>>>>> > >>>>>>>> I'm not certain a time period is really necessary. I=20 > >>>>>>> > >>>>>>> > >>>> > >>>> think this can > >>>> > >>>>>>>> be local option. > >>>>>>>> > >>>>>>>> Even uniqueness across streams isn't *required*, though=20 > >>>>>>> > >>>>>>> > >>>> > >>>> it would be > >>>> > >>>>>>>> helpful. Instead, we can simply introduce an error=20 > >>>>>>> > >>>>>>> > >>>> > >>>> response to be > >>>> > >>>>>>>> used when a duplicate is detected and supressed. If it=20 > >>>>>>> > >>>>>>> > >>>> > >>>> was supressed > >>>> > >>>>>>>> in error because the sender duplicated a TR-ID from=20 > >>>>>>> > >>>>>>> > >>>> > >>>> another stream, > >>>> > >>>>>>>> the sender would then know to recover. > >>>>>>>> > >>>>>>>> But I agree that some further clarification on TR-ID=20 > uniqueness=20 > >>>>>>>> could be helpful. > >>>>>>>> > >>>>>>> > >>>>>>> If TR-ID is not required to be unique across sessions,=20 > >>>>>> > >>>>>> > >>>> > >>>> and you allow > >>>> > >>>>>>> clients to attempt to find duplicate messages using=20 > TR-ID across=20 > >>>>>>> sessions, then you introduce the possibility of false=20 > detection=20 > >>>>>>> caused by TR-ID collisions. This seems bad to me. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Simple mailing list > >>>>>>> Simple@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/simple > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >> > >> > >> > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 12:26:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11498; Tue, 11 Nov 2003 12:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcHk-0006YO-00; Tue, 11 Nov 2003 12:26:36 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJcHj-0006Xa-00; Tue, 11 Nov 2003 12:26:36 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJc6c-00076i-0b; Tue, 11 Nov 2003 12:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc6Y-0002bR-JO; Tue, 11 Nov 2003 12:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc6P-0002aS-Jp for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10813 for ; Tue, 11 Nov 2003 12:14:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJc6O-0006Kd-00 for simple@ietf.org; Tue, 11 Nov 2003 12:14:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJc6N-0006Ka-00 for simple@ietf.org; Tue, 11 Nov 2003 12:14:51 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABHEos13668 for ; Tue, 11 Nov 2003 19:14:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 19:14:50 +0200 Received: from nokia.com ([10.241.48.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 19:14:50 +0200 Message-ID: <3FB11907.4030607@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> <3FB10453.3000902@dynamicsoft.com> In-Reply-To: <3FB10453.3000902@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 17:14:50.0463 (UTC) FILETIME=[50AD86F0:01C3A877] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 19:14:47 +0200 Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: > Adam Roach wrote: > >> hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: >> >> >>> text/plain does not tell you there is a file attached. I believe it >>> has its own mime type. >> >> >> >> Errmm... no. The mime type doesn't indicate anything about whether >> the content is supposed to be rendered to the user or saved to a >> file. What you're thinking of is Content-Disposition. >> >> http://www.ietf.org/rfc/rfc2183.txt >> >> So, if you wanted to hint that a text/plain payload should be saved >> instead of rendered, I would submit that adding a Content-Disposition >> header to MSRP would achieve the effect you want. > > > Use of content-disposition is interesting, for the reason you mention, > that is to suggest how to render a particular message. I am certainly > open to allowing it in an MSRP message. > > But to head off any proposal of saying we should use this to label the > purpose of an entire _session, I think if we were going to go so far as > to carry content-disposition in the SDP, we could come up with something > both syntactically simpler and better fitting the semantic. These are somewhat orthogonal aspects of a message session. It is probably useful to label a specific session as e.g., file-transfer, as well as set some other properties like whether it is uni- or bidirectional. It is another thing to state the disposition of a message. Although in a file transfer session, all messages would likely have the same disposition (like "attachment"), it would still be useful to list other things like filename per each message. Cheers, Aki > >> >> /a >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 12:26:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11646 for ; Tue, 11 Nov 2003 12:26:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcHo-0003jp-9d for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:26:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHQeAs014368 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:26:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcHm-0003jf-OZ for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:26:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11498; Tue, 11 Nov 2003 12:26:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcHk-0006YO-00; Tue, 11 Nov 2003 12:26:36 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJcHj-0006Xa-00; Tue, 11 Nov 2003 12:26:36 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJc6c-00076i-0b; Tue, 11 Nov 2003 12:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc6Y-0002bR-JO; Tue, 11 Nov 2003 12:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJc6P-0002aS-Jp for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:14:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10813 for ; Tue, 11 Nov 2003 12:14:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJc6O-0006Kd-00 for simple@ietf.org; Tue, 11 Nov 2003 12:14:52 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJc6N-0006Ka-00 for simple@ietf.org; Tue, 11 Nov 2003 12:14:51 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABHEos13668 for ; Tue, 11 Nov 2003 19:14:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 19:14:50 +0200 Received: from nokia.com ([10.241.48.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 19:14:50 +0200 Message-ID: <3FB11907.4030607@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> <3FB10453.3000902@dynamicsoft.com> In-Reply-To: <3FB10453.3000902@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 17:14:50.0463 (UTC) FILETIME=[50AD86F0:01C3A877] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 19:14:47 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: > Adam Roach wrote: > >> hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: >> >> >>> text/plain does not tell you there is a file attached. I believe it >>> has its own mime type. >> >> >> >> Errmm... no. The mime type doesn't indicate anything about whether >> the content is supposed to be rendered to the user or saved to a >> file. What you're thinking of is Content-Disposition. >> >> http://www.ietf.org/rfc/rfc2183.txt >> >> So, if you wanted to hint that a text/plain payload should be saved >> instead of rendered, I would submit that adding a Content-Disposition >> header to MSRP would achieve the effect you want. > > > Use of content-disposition is interesting, for the reason you mention, > that is to suggest how to render a particular message. I am certainly > open to allowing it in an MSRP message. > > But to head off any proposal of saying we should use this to label the > purpose of an entire _session, I think if we were going to go so far as > to carry content-disposition in the SDP, we could come up with something > both syntactically simpler and better fitting the semantic. These are somewhat orthogonal aspects of a message session. It is probably useful to label a specific session as e.g., file-transfer, as well as set some other properties like whether it is uni- or bidirectional. It is another thing to state the disposition of a message. Although in a file transfer session, all messages would likely have the same disposition (like "attachment"), it would still be useful to list other things like filename per each message. Cheers, Aki > >> >> /a >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 12:30:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11860; Tue, 11 Nov 2003 12:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcLl-0006gp-00; Tue, 11 Nov 2003 12:30:45 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJcHt-0006Xa-01; Tue, 11 Nov 2003 12:26:45 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJbzx-0006gU-KY; Tue, 11 Nov 2003 12:08:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbzl-00021e-J8; Tue, 11 Nov 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbyw-0001no-H1 for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:07:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10403 for ; Tue, 11 Nov 2003 12:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbyu-0006E5-00 for simple@ietf.org; Tue, 11 Nov 2003 12:07:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJbyt-0006Ds-00 for simple@ietf.org; Tue, 11 Nov 2003 12:07:08 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABH75s05749 for ; Tue, 11 Nov 2003 19:07:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 19:07:05 +0200 Received: from nokia.com ([10.241.48.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 19:07:04 +0200 Message-ID: <3FB11735.3090600@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> <3FB10709.5050403@dynamicsoft.com> In-Reply-To: <3FB10709.5050403@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 17:07:04.0846 (UTC) FILETIME=[3B2602E0:01C3A876] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 19:07:01 +0200 Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: > Paul Kyzivat wrote: > >> I agree that retransmission over the same connection is useless and >> shouldn't be attempted. The issue is retransmission of messages >> pending on the old session when switching to a replacement session. >> That situation can arise if for instance a relay crashes. In that case >> the endpoint may well recover by establishing a new session and >> retransmitting any messages not confirmed on the old one. > > > OK, so to clarify the bounderies of this discussion, we do not think > that retransmission within a particular session is useful. This implies > that duplicate suppression _within_ a session is not particularly > interesting for its on sake. Do the active participants in this > conversation agree with this point? Agreed. > We _are_ however, concerned about how an implementation might _resume_ a > session that has died for whatever reason. By _resume_, I mean create a > new (and unrelated at the protocol level) session that continues the > conversation. In this case, an implementation might choose to re-send > content for which receiption on the previous session could not be > confirmed. If this occurs, it may be interesting to have a cross-session > duplicate suppression mechanism. There is still open discussion on > whether this is needed at all, and if so, should it be required or > optional. We pretty much agree that if we were to do something like > this, it would involve TR-ID, but there is still open discussion on how > strong of requirements we would need for uniqueness, and remembering > past values. Do the active participants in this conversation agree that > this is the current state of the controversy? Yes. I think the first thing to understand is how the end point deals with a failing session. If it tears down the session (i.e., a SIP BYE) in case messages time out or a connection is dropped, then resuming a session under these conditions is identical to resuming any old message session. This suggests some sort of support for message threads, or session identifiers, and as you also hint, goes beyond what the TR-ID is supposed to do. Cheers, Aki >> >> Of course Hisham is right that it is possible to leave the decision to >> retransmit to the user of the application. This has a couple of problems: >> - the end user presumably doesn't have access to tools for suppressing >> duplicates. So in cases where the old message had been process but the >> response not delivered this will result in a duplicate message. This >> can be mitigated somewhat by clarifying conversation between the users >> at the two ends. >> >> - automata at one end or the other will be further limited. They are >> likely to be less tolerant of problems and less able to mitigate the >> problems via informal communication. >> > > I would hope that automata would be designed so that duplicates cause no > harm--but I guess it is hard to guarantee that. I must also point out > that our primary use case is delivering messages to humans. While we do > not prohibit automata, we have generally not included requirements that > are specific to automata processing. > >> Paul >> >> Paul >> >> Ben Campbell wrote: >> >>> In spite of the fact I keep letting myself get trapped into talking >>> about retransmitting, I think I agree. If one attempt fails, it seems >>> highly unlikely another attempt will suddenly succeed. >>> >>> hisham.khartabil@nokia.com wrote: >>> >>>> Again I ask: why is there a need for retransmission? As I said >>>> earlier, if a message fails (timeout or 5xx), the end user gets >>>> presented with this error and it is up to him/her to send it again. >>>> >>>> If it was a long message and a timeout has occurred, then only the >>>> user can decide to send it again (again I'm pointing out that long >>>> messages can wrongly time out) >>>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Tuesday, November 11, 2003 12:27 AM >>>>> To: Ben Campbell >>>>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>>>> simple@ietf.org >>>>> Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>>>> >>>>> >>>>> Its true that within a given session it should be sufficient to >>>>> distinguish between the currently pending messages. So TR-IDs for >>>>> acknowledged messages could be recycled. >>>>> >>>>> OTOH, without some tweaks that makes the problem of failing over to >>>>> another session harder. >>>>> >>>>> This could perhaps be handled by making a two-part TR-ID: >>>>> .. So when a session is established for the first >>>>> time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>>>> fail over to a new session, then ids for new messages are 2.1, 2.2, >>>>> ..., but retransmissions of old ones would still carry their >>>>> original TR-ID. >>>>> >>>>> A recipient that supports duplicate suppression would need to >>>>> remember the ids of messages processed until certain the response >>>>> had been received by the sender. This could be handled a number of >>>>> different ways: >>>>> - reuse of a TR-ID in the *same* session isn't a retransmission. It >>>>> redefines what message it applies to. >>>>> - if a request is sent in the other direction, any responses sent >>>>> prior to it can be inferred to have been received, so the messages >>>>> corresponding to those responses will no longer be eligible for >>>>> retransmission. >>>>> - the timeout interval for messages puts an upper bound on how >>>>> long one needs to be prepared to deal with retransmissions of >>>>> a message. >>>>> >>>>> Paul >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> Aki Niemi wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> At this point I'm really confused about the true meaning for TR-ID. >>>>>>> >>>>>>> The current draft reads to me that the TR-ID should be >>>>>> >>>>>> >>>>>> >>>>> >>>>> unique within a >>>>> >>>>>>> session, but there still isn't any duplicate suppression on the >>>>>>> recipient side. If this is the case, I don't even see why >>>>>> >>>>>> >>>>>> >>>>> >>>>> TR-ID needs >>>>> >>>>>>> to be unique within a session. It would seem enough for >>>>>> >>>>>> >>>>>> >>>>> >>>>> the sender not >>>>> >>>>>>> to have TR-ID collisions occur within the set of *pending* >>>>>> >>>>>> >>>>>> >>>>> >>>>> requests. >>>>> >>>>>>> in other words, the TR-ID is opaque to the recipient - >>>>>> >>>>>> >>>>>> >>>>> >>>>> whatever the 5 >>>>> >>>>>>> request had is used in the response. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The real requirement for the current usage is exactly as >>>>> >>>>> >>>>> >>>>> >>>>> you say, that >>>>> >>>>>> is, no collisions within the set of pending requests. >>>>> >>>>> >>>>> >>>>> >>>>> Making them unique >>>>> >>>>>> inside a session simply seemed the easiest way to enforce this. >>>>>> >>>>>> >>>>>>> Having said that, I think TR-ID is not working to its full >>>>>> >>>>>> >>>>>> >>>>> >>>>> potential, >>>>> >>>>>>> and thus I have a new proposal. >>>>>>> >>>>>>> Let's make TR-ID a simple counter. Each session starts >>>>>> >>>>>> >>>>>> >>>>> >>>>> from zero, and >>>>> >>>>>>> each new message increments this counter. We can come up with a >>>>>>> reasonable resolution for this counter; x seems as good a value >>>>>>> as any. When the counter hits x, it is reset to zero. >>>>>>> The good thing is that we get duplicate detection without the >>>>>>> recipient having to remember all used TR-IDs within a >>>>>> >>>>>> >>>>>> >>>>> >>>>> session, but it >>>>> >>>>>>> suffices to maintain this unidirectional counter on each end. >>>>>>> >>>>>>> Whatever the resolution will be, it seems a reasonable >>>>>> >>>>>> >>>>>> >>>>> >>>>> limitation to >>>>> >>>>>>> say that a sender can only have x pending requests at a time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This is interesting. We originally avoided this approach due to >>>>>> potential problems with shared connections, etc. These >>>>> >>>>> >>>>> >>>>> >>>>> problems may all >>>>> >>>>>> be gone with the current version. One potential problem >>>>> >>>>> >>>>> >>>>> >>>>> comes to mind >>>>> >>>>>> is, if TR-ID 2 times out _and_ was never presented to the >>>>> >>>>> >>>>> >>>>> >>>>> recipient, >>>>> >>>>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >>>>> >>>>> >>>>> >>>>> >>>>> falsely be >>>>> >>>>>> treated as a duplicate. Now, I am not sure this can really happen >>>>>> assuming TCP connections all the way. If the receiving peer is >>>>>> overloaded, but recovers well enough to process TR-ID 3, >>>>> >>>>> >>>>> >>>>> >>>>> then TR-ID 2 >>>>> >>>>>> will most likely get processed first anyway, wouldn't it? >>>>>> >>>>>> Does anyone recall a problem with requiring ordered, >>>>> >>>>> >>>>> >>>>> >>>>> contiguous TR-ID >>>>> >>>>>> values, and allowing the receiving peer to notice >>>>> >>>>> >>>>> >>>>> >>>>> discrepancies, that is >>>>> >>>>>> still relevant? >>>>>> >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> Aki >>>>>>> >>>>>>> ext Ben Campbell wrote: >>>>>>> >>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>> >>>>>>>>> I'm not certain a time period is really necessary. I >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> think this can >>>>> >>>>>>>>> be local option. >>>>>>>>> >>>>>>>>> Even uniqueness across streams isn't *required*, though >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> it would be >>>>> >>>>>>>>> helpful. Instead, we can simply introduce an error >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> response to be >>>>> >>>>>>>>> used when a duplicate is detected and supressed. If it >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> was supressed >>>>> >>>>>>>>> in error because the sender duplicated a TR-ID from >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> another stream, >>>>> >>>>>>>>> the sender would then know to recover. >>>>>>>>> >>>>>>>>> But I agree that some further clarification on TR-ID uniqueness >>>>>>>>> could be helpful. >>>>>>>>> >>>>>>>> >>>>>>>> If TR-ID is not required to be unique across sessions, >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> and you allow >>>>> >>>>>>>> clients to attempt to find duplicate messages using TR-ID across >>>>>>>> sessions, then you introduce the possibility of false detection >>>>>>>> caused by TR-ID collisions. This seems bad to me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 exim@www1.ietf.org Tue Nov 11 12:31:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11930 for ; Tue, 11 Nov 2003 12:31:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcLo-0004FV-6K for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:30:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHUmeX016327 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcLo-0004FG-1Q for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11860; Tue, 11 Nov 2003 12:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcLl-0006gp-00; Tue, 11 Nov 2003 12:30:45 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AJcHt-0006Xa-01; Tue, 11 Nov 2003 12:26:45 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AJbzx-0006gU-KY; Tue, 11 Nov 2003 12:08:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbzl-00021e-J8; Tue, 11 Nov 2003 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJbyw-0001no-H1 for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:07:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10403 for ; Tue, 11 Nov 2003 12:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJbyu-0006E5-00 for simple@ietf.org; Tue, 11 Nov 2003 12:07:08 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJbyt-0006Ds-00 for simple@ietf.org; Tue, 11 Nov 2003 12:07:08 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABH75s05749 for ; Tue, 11 Nov 2003 19:07:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 19:07:05 +0200 Received: from nokia.com ([10.241.48.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 19:07:04 +0200 Message-ID: <3FB11735.3090600@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: Paul Kyzivat , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> <3FB10709.5050403@dynamicsoft.com> In-Reply-To: <3FB10709.5050403@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 17:07:04.0846 (UTC) FILETIME=[3B2602E0:01C3A876] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 19:07:01 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Ben Campbell wrote: > Paul Kyzivat wrote: > >> I agree that retransmission over the same connection is useless and >> shouldn't be attempted. The issue is retransmission of messages >> pending on the old session when switching to a replacement session. >> That situation can arise if for instance a relay crashes. In that case >> the endpoint may well recover by establishing a new session and >> retransmitting any messages not confirmed on the old one. > > > OK, so to clarify the bounderies of this discussion, we do not think > that retransmission within a particular session is useful. This implies > that duplicate suppression _within_ a session is not particularly > interesting for its on sake. Do the active participants in this > conversation agree with this point? Agreed. > We _are_ however, concerned about how an implementation might _resume_ a > session that has died for whatever reason. By _resume_, I mean create a > new (and unrelated at the protocol level) session that continues the > conversation. In this case, an implementation might choose to re-send > content for which receiption on the previous session could not be > confirmed. If this occurs, it may be interesting to have a cross-session > duplicate suppression mechanism. There is still open discussion on > whether this is needed at all, and if so, should it be required or > optional. We pretty much agree that if we were to do something like > this, it would involve TR-ID, but there is still open discussion on how > strong of requirements we would need for uniqueness, and remembering > past values. Do the active participants in this conversation agree that > this is the current state of the controversy? Yes. I think the first thing to understand is how the end point deals with a failing session. If it tears down the session (i.e., a SIP BYE) in case messages time out or a connection is dropped, then resuming a session under these conditions is identical to resuming any old message session. This suggests some sort of support for message threads, or session identifiers, and as you also hint, goes beyond what the TR-ID is supposed to do. Cheers, Aki >> >> Of course Hisham is right that it is possible to leave the decision to >> retransmit to the user of the application. This has a couple of problems: >> - the end user presumably doesn't have access to tools for suppressing >> duplicates. So in cases where the old message had been process but the >> response not delivered this will result in a duplicate message. This >> can be mitigated somewhat by clarifying conversation between the users >> at the two ends. >> >> - automata at one end or the other will be further limited. They are >> likely to be less tolerant of problems and less able to mitigate the >> problems via informal communication. >> > > I would hope that automata would be designed so that duplicates cause no > harm--but I guess it is hard to guarantee that. I must also point out > that our primary use case is delivering messages to humans. While we do > not prohibit automata, we have generally not included requirements that > are specific to automata processing. > >> Paul >> >> Paul >> >> Ben Campbell wrote: >> >>> In spite of the fact I keep letting myself get trapped into talking >>> about retransmitting, I think I agree. If one attempt fails, it seems >>> highly unlikely another attempt will suddenly succeed. >>> >>> hisham.khartabil@nokia.com wrote: >>> >>>> Again I ask: why is there a need for retransmission? As I said >>>> earlier, if a message fails (timeout or 5xx), the end user gets >>>> presented with this error and it is up to him/her to send it again. >>>> >>>> If it was a long message and a timeout has occurred, then only the >>>> user can decide to send it again (again I'm pointing out that long >>>> messages can wrongly time out) >>>> >>>> /Hisham >>>> >>>> >>>>> -----Original Message----- >>>>> From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>> Sent: Tuesday, November 11, 2003 12:27 AM >>>>> To: Ben Campbell >>>>> Cc: Niemi Aki (NMP/Helsinki); Khartabil Hisham (NMP-MSW/Helsinki); >>>>> simple@ietf.org >>>>> Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>>>> >>>>> >>>>> Its true that within a given session it should be sufficient to >>>>> distinguish between the currently pending messages. So TR-IDs for >>>>> acknowledged messages could be recycled. >>>>> >>>>> OTOH, without some tweaks that makes the problem of failing over to >>>>> another session harder. >>>>> >>>>> This could perhaps be handled by making a two-part TR-ID: >>>>> .. So when a session is established for the first >>>>> time, ids are of the form 1.1, 1.2, ... Then, if it is necessary to >>>>> fail over to a new session, then ids for new messages are 2.1, 2.2, >>>>> ..., but retransmissions of old ones would still carry their >>>>> original TR-ID. >>>>> >>>>> A recipient that supports duplicate suppression would need to >>>>> remember the ids of messages processed until certain the response >>>>> had been received by the sender. This could be handled a number of >>>>> different ways: >>>>> - reuse of a TR-ID in the *same* session isn't a retransmission. It >>>>> redefines what message it applies to. >>>>> - if a request is sent in the other direction, any responses sent >>>>> prior to it can be inferred to have been received, so the messages >>>>> corresponding to those responses will no longer be eligible for >>>>> retransmission. >>>>> - the timeout interval for messages puts an upper bound on how >>>>> long one needs to be prepared to deal with retransmissions of >>>>> a message. >>>>> >>>>> Paul >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> Aki Niemi wrote: >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> At this point I'm really confused about the true meaning for TR-ID. >>>>>>> >>>>>>> The current draft reads to me that the TR-ID should be >>>>>> >>>>>> >>>>>> >>>>> >>>>> unique within a >>>>> >>>>>>> session, but there still isn't any duplicate suppression on the >>>>>>> recipient side. If this is the case, I don't even see why >>>>>> >>>>>> >>>>>> >>>>> >>>>> TR-ID needs >>>>> >>>>>>> to be unique within a session. It would seem enough for >>>>>> >>>>>> >>>>>> >>>>> >>>>> the sender not >>>>> >>>>>>> to have TR-ID collisions occur within the set of *pending* >>>>>> >>>>>> >>>>>> >>>>> >>>>> requests. >>>>> >>>>>>> in other words, the TR-ID is opaque to the recipient - >>>>>> >>>>>> >>>>>> >>>>> >>>>> whatever the 5 >>>>> >>>>>>> request had is used in the response. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The real requirement for the current usage is exactly as >>>>> >>>>> >>>>> >>>>> >>>>> you say, that >>>>> >>>>>> is, no collisions within the set of pending requests. >>>>> >>>>> >>>>> >>>>> >>>>> Making them unique >>>>> >>>>>> inside a session simply seemed the easiest way to enforce this. >>>>>> >>>>>> >>>>>>> Having said that, I think TR-ID is not working to its full >>>>>> >>>>>> >>>>>> >>>>> >>>>> potential, >>>>> >>>>>>> and thus I have a new proposal. >>>>>>> >>>>>>> Let's make TR-ID a simple counter. Each session starts >>>>>> >>>>>> >>>>>> >>>>> >>>>> from zero, and >>>>> >>>>>>> each new message increments this counter. We can come up with a >>>>>>> reasonable resolution for this counter; x seems as good a value >>>>>>> as any. When the counter hits x, it is reset to zero. >>>>>>> The good thing is that we get duplicate detection without the >>>>>>> recipient having to remember all used TR-IDs within a >>>>>> >>>>>> >>>>>> >>>>> >>>>> session, but it >>>>> >>>>>>> suffices to maintain this unidirectional counter on each end. >>>>>>> >>>>>>> Whatever the resolution will be, it seems a reasonable >>>>>> >>>>>> >>>>>> >>>>> >>>>> limitation to >>>>> >>>>>>> say that a sender can only have x pending requests at a time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This is interesting. We originally avoided this approach due to >>>>>> potential problems with shared connections, etc. These >>>>> >>>>> >>>>> >>>>> >>>>> problems may all >>>>> >>>>>> be gone with the current version. One potential problem >>>>> >>>>> >>>>> >>>>> >>>>> comes to mind >>>>> >>>>>> is, if TR-ID 2 times out _and_ was never presented to the >>>>> >>>>> >>>>> >>>>> >>>>> recipient, >>>>> >>>>>> TR-ID 3 is delivered, then TR-ID 2 is resubmitted, it may >>>>> >>>>> >>>>> >>>>> >>>>> falsely be >>>>> >>>>>> treated as a duplicate. Now, I am not sure this can really happen >>>>>> assuming TCP connections all the way. If the receiving peer is >>>>>> overloaded, but recovers well enough to process TR-ID 3, >>>>> >>>>> >>>>> >>>>> >>>>> then TR-ID 2 >>>>> >>>>>> will most likely get processed first anyway, wouldn't it? >>>>>> >>>>>> Does anyone recall a problem with requiring ordered, >>>>> >>>>> >>>>> >>>>> >>>>> contiguous TR-ID >>>>> >>>>>> values, and allowing the receiving peer to notice >>>>> >>>>> >>>>> >>>>> >>>>> discrepancies, that is >>>>> >>>>>> still relevant? >>>>>> >>>>>> >>>>>> >>>>>>> Cheers, >>>>>>> Aki >>>>>>> >>>>>>> ext Ben Campbell wrote: >>>>>>> >>>>>>> >>>>>>>> Paul Kyzivat wrote: >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>> >>>>>>>>> I'm not certain a time period is really necessary. I >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> think this can >>>>> >>>>>>>>> be local option. >>>>>>>>> >>>>>>>>> Even uniqueness across streams isn't *required*, though >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> it would be >>>>> >>>>>>>>> helpful. Instead, we can simply introduce an error >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> response to be >>>>> >>>>>>>>> used when a duplicate is detected and supressed. If it >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> was supressed >>>>> >>>>>>>>> in error because the sender duplicated a TR-ID from >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> another stream, >>>>> >>>>>>>>> the sender would then know to recover. >>>>>>>>> >>>>>>>>> But I agree that some further clarification on TR-ID uniqueness >>>>>>>>> could be helpful. >>>>>>>>> >>>>>>>> >>>>>>>> If TR-ID is not required to be unique across sessions, >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> and you allow >>>>> >>>>>>>> clients to attempt to find duplicate messages using TR-ID across >>>>>>>> sessions, then you introduce the possibility of false detection >>>>>>>> caused by TR-ID collisions. This seems bad to me. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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-admin@ietf.org Tue Nov 11 12:36:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12392; Tue, 11 Nov 2003 12:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcRv-0006qA-00; Tue, 11 Nov 2003 12:37:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcRu-0006q7-00; Tue, 11 Nov 2003 12:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcRp-0004lV-6F; Tue, 11 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcRC-0004kx-FF for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12345 for ; Tue, 11 Nov 2003 12:36:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcRA-0006p0-00 for simple@ietf.org; Tue, 11 Nov 2003 12:36:20 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJcRA-0006oh-00 for simple@ietf.org; Tue, 11 Nov 2003 12:36:20 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hABHRIGd016517; Tue, 11 Nov 2003 11:27:19 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 11:27:18 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Aki Niemi'" , Ben Campbell Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on message-sessions-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 11:27:16 -0600 Aki Niemi [mailto:aki.niemi@nokia.com] writes: > These are somewhat orthogonal aspects of a message session. It is > probably useful to label a specific session as e.g., file-transfer Yes. You do this by using port 21. If you know a priori that all you are going to do is transfer files, the IETF has already defined a file transfer protocol. > It is another thing to state the disposition of a message. > Although in a file transfer session, all messages would likely > have the same disposition (like "attachment"), it would still > be useful to list other things like filename per each message. I think you want the "filename" parameter defined in RFC 2183. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 12:37:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12419 for ; Tue, 11 Nov 2003 12:37:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcRx-0004qg-Vb for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHb9Fd018632 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcRx-0004qR-Ae for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12392; Tue, 11 Nov 2003 12:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcRv-0006qA-00; Tue, 11 Nov 2003 12:37:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJcRu-0006q7-00; Tue, 11 Nov 2003 12:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcRp-0004lV-6F; Tue, 11 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcRC-0004kx-FF for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12345 for ; Tue, 11 Nov 2003 12:36:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcRA-0006p0-00 for simple@ietf.org; Tue, 11 Nov 2003 12:36:20 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJcRA-0006oh-00 for simple@ietf.org; Tue, 11 Nov 2003 12:36:20 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hABHRIGd016517; Tue, 11 Nov 2003 11:27:19 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 11:27:18 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Aki Niemi'" , Ben Campbell Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on message-sessions-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 11:27:16 -0600 Aki Niemi [mailto:aki.niemi@nokia.com] writes: > These are somewhat orthogonal aspects of a message session. It is > probably useful to label a specific session as e.g., file-transfer Yes. You do this by using port 21. If you know a priori that all you are going to do is transfer files, the IETF has already defined a file transfer protocol. > It is another thing to state the disposition of a message. > Although in a file transfer session, all messages would likely > have the same disposition (like "attachment"), it would still > be useful to list other things like filename per each message. I think you want the "filename" parameter defined in RFC 2183. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 12:55:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13478; Tue, 11 Nov 2003 12:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJckE-0007Bs-00; Tue, 11 Nov 2003 12:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJckE-0007Bp-00; Tue, 11 Nov 2003 12:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJckD-0006gC-HU; Tue, 11 Nov 2003 12:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcjY-0006UE-NK for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:55:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13440 for ; Tue, 11 Nov 2003 12:55:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcjW-0007BN-00 for simple@ietf.org; Tue, 11 Nov 2003 12:55:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJcjW-0007BK-00 for simple@ietf.org; Tue, 11 Nov 2003 12:55:18 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABHtHB09820 for ; Tue, 11 Nov 2003 19:55:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 19:55:10 +0200 Received: from nokia.com ([10.162.14.236]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 19:55:08 +0200 Message-ID: <3FB1227A.8060705@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Adam Roach CC: Ben Campbell , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 17:55:08.0902 (UTC) FILETIME=[F22E0860:01C3A87C] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 19:55:06 +0200 Content-Transfer-Encoding: 7bit ext Adam Roach wrote: > Aki Niemi [mailto:aki.niemi@nokia.com] writes: > > >>These are somewhat orthogonal aspects of a message session. It is >>probably useful to label a specific session as e.g., file-transfer > > > Yes. You do this by using port 21. If you know a priori that all > you are going to do is transfer files, the IETF has already > defined a file transfer protocol. Right. And if you know a priori that all you are going to do is chat with the other party, then just use IRC. Great, we're done. Thanks, Aki > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 12:56:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13503 for ; Tue, 11 Nov 2003 12:56:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJckH-0006i9-MU for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABHu563025791 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 12:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJckH-0006hu-Hk for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 12:56:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13478; Tue, 11 Nov 2003 12:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJckE-0007Bs-00; Tue, 11 Nov 2003 12:56:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJckE-0007Bp-00; Tue, 11 Nov 2003 12:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJckD-0006gC-HU; Tue, 11 Nov 2003 12:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJcjY-0006UE-NK for simple@optimus.ietf.org; Tue, 11 Nov 2003 12:55:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13440 for ; Tue, 11 Nov 2003 12:55:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJcjW-0007BN-00 for simple@ietf.org; Tue, 11 Nov 2003 12:55:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJcjW-0007BK-00 for simple@ietf.org; Tue, 11 Nov 2003 12:55:18 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABHtHB09820 for ; Tue, 11 Nov 2003 19:55:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 19:55:10 +0200 Received: from nokia.com ([10.162.14.236]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 19:55:08 +0200 Message-ID: <3FB1227A.8060705@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Adam Roach CC: Ben Campbell , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 17:55:08.0902 (UTC) FILETIME=[F22E0860:01C3A87C] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 19:55:06 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ext Adam Roach wrote: > Aki Niemi [mailto:aki.niemi@nokia.com] writes: > > >>These are somewhat orthogonal aspects of a message session. It is >>probably useful to label a specific session as e.g., file-transfer > > > Yes. You do this by using port 21. If you know a priori that all > you are going to do is transfer files, the IETF has already > defined a file transfer protocol. Right. And if you know a priori that all you are going to do is chat with the other party, then just use IRC. Great, we're done. Thanks, Aki > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 14:07:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15811; Tue, 11 Nov 2003 14:07:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdrv-0000JZ-00; Tue, 11 Nov 2003 14:08:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdru-0000JW-00; Tue, 11 Nov 2003 14:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdrt-0003cf-GW; Tue, 11 Nov 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdrQ-0003Uy-23 for simple@optimus.ietf.org; Tue, 11 Nov 2003 14:07:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15801 for ; Tue, 11 Nov 2003 14:07:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdrN-0000J6-00 for simple@ietf.org; Tue, 11 Nov 2003 14:07:29 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJdrM-0000J2-00 for simple@ietf.org; Tue, 11 Nov 2003 14:07:29 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABJ7GIc069801; Tue, 11 Nov 2003 13:07:22 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB13362.4050405@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> <3FB1227A.8060705@nokia.com> In-Reply-To: <3FB1227A.8060705@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:07:14 -0600 Content-Transfer-Encoding: 7bit From section 5.1: "An analysis of whether it makes sense to do this [file transfer or sending very large content], rather than sending such content over FTP, HTTP, or some other such protocol, is beyond the scope of this document." I originally took (and still agree with) Adam's position, but that is clearly not the consensus of this group. (If I am incorrect in that belief, I would love to hear it as I could remove quite a bit of text.) Aki Niemi wrote: > > > ext Adam Roach wrote: > >> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >> >> >>> These are somewhat orthogonal aspects of a message session. It is >>> probably useful to label a specific session as e.g., file-transfer >> >> >> >> Yes. You do this by using port 21. If you know a priori that all >> you are going to do is transfer files, the IETF has already >> defined a file transfer protocol. > > > Right. And if you know a priori that all you are going to do is chat > with the other party, then just use IRC. Great, we're done. > > Thanks, > Aki > > >> /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 14:08:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15834 for ; Tue, 11 Nov 2003 14:08:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJds0-0003fH-5a for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 14:08:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJ88Wx014065 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 14:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdrz-0003em-5e for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:08:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15811; Tue, 11 Nov 2003 14:07:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdrv-0000JZ-00; Tue, 11 Nov 2003 14:08:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJdru-0000JW-00; Tue, 11 Nov 2003 14:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdrt-0003cf-GW; Tue, 11 Nov 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJdrQ-0003Uy-23 for simple@optimus.ietf.org; Tue, 11 Nov 2003 14:07:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15801 for ; Tue, 11 Nov 2003 14:07:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJdrN-0000J6-00 for simple@ietf.org; Tue, 11 Nov 2003 14:07:29 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJdrM-0000J2-00 for simple@ietf.org; Tue, 11 Nov 2003 14:07:29 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABJ7GIc069801; Tue, 11 Nov 2003 13:07:22 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB13362.4050405@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> <3FB1227A.8060705@nokia.com> In-Reply-To: <3FB1227A.8060705@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:07:14 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit From section 5.1: "An analysis of whether it makes sense to do this [file transfer or sending very large content], rather than sending such content over FTP, HTTP, or some other such protocol, is beyond the scope of this document." I originally took (and still agree with) Adam's position, but that is clearly not the consensus of this group. (If I am incorrect in that belief, I would love to hear it as I could remove quite a bit of text.) Aki Niemi wrote: > > > ext Adam Roach wrote: > >> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >> >> >>> These are somewhat orthogonal aspects of a message session. It is >>> probably useful to label a specific session as e.g., file-transfer >> >> >> >> Yes. You do this by using port 21. If you know a priori that all >> you are going to do is transfer files, the IETF has already >> defined a file transfer protocol. > > > Right. And if you know a priori that all you are going to do is chat > with the other party, then just use IRC. Great, we're done. > > Thanks, > Aki > > >> /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 14:22:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16331; Tue, 11 Nov 2003 14:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe6U-0000TV-00; Tue, 11 Nov 2003 14:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJe6T-0000TS-00; Tue, 11 Nov 2003 14:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe6O-0004UU-GC; Tue, 11 Nov 2003 14:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe5r-0004Te-Pb for simple@optimus.ietf.org; Tue, 11 Nov 2003 14:22:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16286 for ; Tue, 11 Nov 2003 14:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe5p-0000T9-00 for simple@ietf.org; Tue, 11 Nov 2003 14:22:25 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJe5o-0000T6-00 for simple@ietf.org; Tue, 11 Nov 2003 14:22:24 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABJMNB05292 for ; Tue, 11 Nov 2003 21:22:23 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 21:22:21 +0200 Received: from nokia.com ([10.162.15.240]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 21:22:21 +0200 Message-ID: <3FB136EB.5060503@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: ext Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> <3FB1227A.8060705@nokia.com> <3FB13362.4050405@dynamicsoft.com> In-Reply-To: <3FB13362.4050405@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 19:22:21.0181 (UTC) FILETIME=[20DC72D0:01C3A889] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 21:22:19 +0200 Content-Transfer-Encoding: 7bit Hi, Perhaps I should also clarify my position. Clearly, if you are going to just do file transfer, there is no sense at all to start to develop something else but to use FTP. But this is not the case here. We are developing MSRP to enable sending messages in a session, negotiating this in SIP/SDP, and have tools to invoke relays for these sessions. Now, it is also possible *and* useful to send files, or things other than text/plain, in this session - at which point it becomes "file transfer". Please explain why this is bad practice just because IETF already has another protocol to do "file transfer"? It's not like we are re-developing TCP here. If we were, I'd share your concerns. As I understand it, in the hour-glass model of Internet, multiple application layer protocols that may even overlap in functionality is not a bad thing. Cheers, Aki ext Ben Campbell wrote: > From section 5.1: > > "An analysis of whether it makes sense to do this [file transfer or > sending very large content], rather than sending such content over FTP, > HTTP, or some other such protocol, is beyond the scope of this document." > > I originally took (and still agree with) Adam's position, but that is > clearly not the consensus of this group. (If I am incorrect in that > belief, I would love to hear it as I could remove quite a bit of text.) > > > Aki Niemi wrote: > >> >> >> ext Adam Roach wrote: >> >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >>> >>> >>>> These are somewhat orthogonal aspects of a message session. It is >>>> probably useful to label a specific session as e.g., file-transfer >>> >>> >>> >>> >>> Yes. You do this by using port 21. If you know a priori that all >>> you are going to do is transfer files, the IETF has already >>> defined a file transfer protocol. >> >> >> >> Right. And if you know a priori that all you are going to do is chat >> with the other party, then just use IRC. Great, we're done. >> >> Thanks, >> Aki >> >> >>> /a > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 14:23:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16353 for ; Tue, 11 Nov 2003 14:23:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe6Z-0004Wr-Cp for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 14:23:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJNBnR017403 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 14:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe6X-0004Wc-SR for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16331; Tue, 11 Nov 2003 14:22:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe6U-0000TV-00; Tue, 11 Nov 2003 14:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJe6T-0000TS-00; Tue, 11 Nov 2003 14:23:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe6O-0004UU-GC; Tue, 11 Nov 2003 14:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJe5r-0004Te-Pb for simple@optimus.ietf.org; Tue, 11 Nov 2003 14:22:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16286 for ; Tue, 11 Nov 2003 14:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJe5p-0000T9-00 for simple@ietf.org; Tue, 11 Nov 2003 14:22:25 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJe5o-0000T6-00 for simple@ietf.org; Tue, 11 Nov 2003 14:22:24 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hABJMNB05292 for ; Tue, 11 Nov 2003 21:22:23 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 21:22:21 +0200 Received: from nokia.com ([10.162.15.240]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 21:22:21 +0200 Message-ID: <3FB136EB.5060503@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Ben Campbell CC: ext Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> <3FB1227A.8060705@nokia.com> <3FB13362.4050405@dynamicsoft.com> In-Reply-To: <3FB13362.4050405@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2003 19:22:21.0181 (UTC) FILETIME=[20DC72D0:01C3A889] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 21:22:19 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Perhaps I should also clarify my position. Clearly, if you are going to just do file transfer, there is no sense at all to start to develop something else but to use FTP. But this is not the case here. We are developing MSRP to enable sending messages in a session, negotiating this in SIP/SDP, and have tools to invoke relays for these sessions. Now, it is also possible *and* useful to send files, or things other than text/plain, in this session - at which point it becomes "file transfer". Please explain why this is bad practice just because IETF already has another protocol to do "file transfer"? It's not like we are re-developing TCP here. If we were, I'd share your concerns. As I understand it, in the hour-glass model of Internet, multiple application layer protocols that may even overlap in functionality is not a bad thing. Cheers, Aki ext Ben Campbell wrote: > From section 5.1: > > "An analysis of whether it makes sense to do this [file transfer or > sending very large content], rather than sending such content over FTP, > HTTP, or some other such protocol, is beyond the scope of this document." > > I originally took (and still agree with) Adam's position, but that is > clearly not the consensus of this group. (If I am incorrect in that > belief, I would love to hear it as I could remove quite a bit of text.) > > > Aki Niemi wrote: > >> >> >> ext Adam Roach wrote: >> >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >>> >>> >>>> These are somewhat orthogonal aspects of a message session. It is >>>> probably useful to label a specific session as e.g., file-transfer >>> >>> >>> >>> >>> Yes. You do this by using port 21. If you know a priori that all >>> you are going to do is transfer files, the IETF has already >>> defined a file transfer protocol. >> >> >> >> Right. And if you know a priori that all you are going to do is chat >> with the other party, then just use IRC. Great, we're done. >> >> Thanks, >> Aki >> >> >>> /a > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 14:30:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16780; Tue, 11 Nov 2003 14:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeEA-0000ee-00; Tue, 11 Nov 2003 14:31:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJeE9-0000eb-00; Tue, 11 Nov 2003 14:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeEA-0005WD-4u; Tue, 11 Nov 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeDw-0005Md-Ve for simple@optimus.ietf.org; Tue, 11 Nov 2003 14:30:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16760 for ; Tue, 11 Nov 2003 14:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeDu-0000eN-00 for simple@ietf.org; Tue, 11 Nov 2003 14:30:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJeDt-0000eK-00 for simple@ietf.org; Tue, 11 Nov 2003 14:30:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABJUgIc071723; Tue, 11 Nov 2003 13:30:43 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB138DF.9090401@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> <3FB1227A.8060705@nokia.com> <3FB13362.4050405@dynamicsoft.com> <3FB136EB.5060503@nokia.com> In-Reply-To: <3FB136EB.5060503@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:30:39 -0600 Content-Transfer-Encoding: 7bit I think this particular horse has been dead for some time. The point I clearly failed to make in my post is that I have given in on the subject. Aki Niemi wrote: > Hi, > > Perhaps I should also clarify my position. Clearly, if you are going to > just do file transfer, there is no sense at all to start to develop > something else but to use FTP. > > But this is not the case here. We are developing MSRP to enable sending > messages in a session, negotiating this in SIP/SDP, and have tools to > invoke relays for these sessions. > > Now, it is also possible *and* useful to send files, or things other > than text/plain, in this session - at which point it becomes "file > transfer". Please explain why this is bad practice just because IETF > already has another protocol to do "file transfer"? > > It's not like we are re-developing TCP here. If we were, I'd share your > concerns. As I understand it, in the hour-glass model of Internet, > multiple application layer protocols that may even overlap in > functionality is not a bad thing. > > Cheers, > Aki > > ext Ben Campbell wrote: > >> From section 5.1: >> >> "An analysis of whether it makes sense to do this [file transfer or >> sending very large content], rather than sending such content over >> FTP, HTTP, or some other such protocol, is beyond the scope of this >> document." >> >> I originally took (and still agree with) Adam's position, but that is >> clearly not the consensus of this group. (If I am incorrect in that >> belief, I would love to hear it as I could remove quite a bit of text.) >> >> >> Aki Niemi wrote: >> >>> >>> >>> ext Adam Roach wrote: >>> >>>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >>>> >>>> >>>>> These are somewhat orthogonal aspects of a message session. It is >>>>> probably useful to label a specific session as e.g., file-transfer >>>> >>>> >>>> >>>> >>>> >>>> Yes. You do this by using port 21. If you know a priori that all >>>> you are going to do is transfer files, the IETF has already >>>> defined a file transfer protocol. >>> >>> >>> >>> >>> Right. And if you know a priori that all you are going to do is chat >>> with the other party, then just use IRC. Great, we're done. >>> >>> Thanks, >>> Aki >>> >>> >>>> /a >> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 14:31:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16857 for ; Tue, 11 Nov 2003 14:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeEE-0005YQ-9A for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 14:31:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABJV6u5021344 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 14:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeEE-0005YB-24 for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 14:31:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16780; Tue, 11 Nov 2003 14:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeEA-0000ee-00; Tue, 11 Nov 2003 14:31:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJeE9-0000eb-00; Tue, 11 Nov 2003 14:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeEA-0005WD-4u; Tue, 11 Nov 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJeDw-0005Md-Ve for simple@optimus.ietf.org; Tue, 11 Nov 2003 14:30:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16760 for ; Tue, 11 Nov 2003 14:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJeDu-0000eN-00 for simple@ietf.org; Tue, 11 Nov 2003 14:30:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJeDt-0000eK-00 for simple@ietf.org; Tue, 11 Nov 2003 14:30:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hABJUgIc071723; Tue, 11 Nov 2003 13:30:43 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB138DF.9090401@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: ext Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> <3FB1227A.8060705@nokia.com> <3FB13362.4050405@dynamicsoft.com> <3FB136EB.5060503@nokia.com> In-Reply-To: <3FB136EB.5060503@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 13:30:39 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think this particular horse has been dead for some time. The point I clearly failed to make in my post is that I have given in on the subject. Aki Niemi wrote: > Hi, > > Perhaps I should also clarify my position. Clearly, if you are going to > just do file transfer, there is no sense at all to start to develop > something else but to use FTP. > > But this is not the case here. We are developing MSRP to enable sending > messages in a session, negotiating this in SIP/SDP, and have tools to > invoke relays for these sessions. > > Now, it is also possible *and* useful to send files, or things other > than text/plain, in this session - at which point it becomes "file > transfer". Please explain why this is bad practice just because IETF > already has another protocol to do "file transfer"? > > It's not like we are re-developing TCP here. If we were, I'd share your > concerns. As I understand it, in the hour-glass model of Internet, > multiple application layer protocols that may even overlap in > functionality is not a bad thing. > > Cheers, > Aki > > ext Ben Campbell wrote: > >> From section 5.1: >> >> "An analysis of whether it makes sense to do this [file transfer or >> sending very large content], rather than sending such content over >> FTP, HTTP, or some other such protocol, is beyond the scope of this >> document." >> >> I originally took (and still agree with) Adam's position, but that is >> clearly not the consensus of this group. (If I am incorrect in that >> belief, I would love to hear it as I could remove quite a bit of text.) >> >> >> Aki Niemi wrote: >> >>> >>> >>> ext Adam Roach wrote: >>> >>>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >>>> >>>> >>>>> These are somewhat orthogonal aspects of a message session. It is >>>>> probably useful to label a specific session as e.g., file-transfer >>>> >>>> >>>> >>>> >>>> >>>> Yes. You do this by using port 21. If you know a priori that all >>>> you are going to do is transfer files, the IETF has already >>>> defined a file transfer protocol. >>> >>> >>> >>> >>> Right. And if you know a priori that all you are going to do is chat >>> with the other party, then just use IRC. Great, we're done. >>> >>> Thanks, >>> Aki >>> >>> >>>> /a >> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 16:44:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23244; Tue, 11 Nov 2003 16:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgJs-0002eK-00; Tue, 11 Nov 2003 16:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJgJs-0002eF-00; Tue, 11 Nov 2003 16:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgJp-0008Cu-Bo; Tue, 11 Nov 2003 16:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgJY-0008Ca-O5 for simple@optimus.ietf.org; Tue, 11 Nov 2003 16:44:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23233 for ; Tue, 11 Nov 2003 16:44:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgJW-0002e2-00 for simple@ietf.org; Tue, 11 Nov 2003 16:44:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJgJW-0002dY-00 for simple@ietf.org; Tue, 11 Nov 2003 16:44:42 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABLi9w5020593; Tue, 11 Nov 2003 13:44:10 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-116.cisco.com [10.86.242.116]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX32182; Tue, 11 Nov 2003 16:44:08 -0500 (EST) Message-ID: <3FB15828.8080908@cisco.com> 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: Ben Campbell CC: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> <3FB10453.3000902@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 16:44:08 -0500 Content-Transfer-Encoding: 7bit While I can see establishing a separate session when there is a need to do a file transfer, in order to keep it from conflicting with conversation, I don't imagine restricting it to a single file. For instance, if there are many files to be transferred, it is probably better to pipeline them thru one session than to create a single session for them all. So, when trying to distinguish them in SDP, I think the distinction may only be between "interactive" and "batch" or something like that. Content-Disposition does seem about right for indicating when something is a file and what it is called. But do we really need to add Content-Disposition to MSRP for that? Isn't it sufficient to wrap the thing as a part in a multipart in order to get a Content-Disposition mime header for the text/plain? Or so you want to do what sip has done, and permit all the mime headers in the outer message? Paul Ben Campbell wrote: > Adam Roach wrote: > >> hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: >> >> >>> text/plain does not tell you there is a file attached. I believe it >>> has its own mime type. >> >> >> >> Errmm... no. The mime type doesn't indicate anything about whether >> the content is supposed to be rendered to the user or saved to a >> file. What you're thinking of is Content-Disposition. >> >> http://www.ietf.org/rfc/rfc2183.txt >> >> So, if you wanted to hint that a text/plain payload should be saved >> instead of rendered, I would submit that adding a Content-Disposition >> header to MSRP would achieve the effect you want. > > > Use of content-disposition is interesting, for the reason you mention, > that is to suggest how to render a particular message. I am certainly > open to allowing it in an MSRP message. > > But to head off any proposal of saying we should use this to label the > purpose of an entire _session, I think if we were going to go so far as > to carry content-disposition in the SDP, we could come up with something > both syntactically simpler and better fitting the semantic. > > >> >> /a >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 16:45:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23262 for ; Tue, 11 Nov 2003 16:45:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgJw-0008Di-71 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 16:45:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABLj8o7031594 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 16:45:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgJw-0008DV-2q for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 16:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23244; Tue, 11 Nov 2003 16:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgJs-0002eK-00; Tue, 11 Nov 2003 16:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJgJs-0002eF-00; Tue, 11 Nov 2003 16:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgJp-0008Cu-Bo; Tue, 11 Nov 2003 16:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgJY-0008Ca-O5 for simple@optimus.ietf.org; Tue, 11 Nov 2003 16:44:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23233 for ; Tue, 11 Nov 2003 16:44:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgJW-0002e2-00 for simple@ietf.org; Tue, 11 Nov 2003 16:44:42 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJgJW-0002dY-00 for simple@ietf.org; Tue, 11 Nov 2003 16:44:42 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABLi9w5020593; Tue, 11 Nov 2003 13:44:10 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-116.cisco.com [10.86.242.116]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX32182; Tue, 11 Nov 2003 16:44:08 -0500 (EST) Message-ID: <3FB15828.8080908@cisco.com> 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: Ben Campbell CC: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <9BF66EBF6BEFD942915B4D4D45C051F3E865ED@dyn-tx-exch-001.dynamicsoft.com> <3FB10453.3000902@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 16:44:08 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit While I can see establishing a separate session when there is a need to do a file transfer, in order to keep it from conflicting with conversation, I don't imagine restricting it to a single file. For instance, if there are many files to be transferred, it is probably better to pipeline them thru one session than to create a single session for them all. So, when trying to distinguish them in SDP, I think the distinction may only be between "interactive" and "batch" or something like that. Content-Disposition does seem about right for indicating when something is a file and what it is called. But do we really need to add Content-Disposition to MSRP for that? Isn't it sufficient to wrap the thing as a part in a multipart in order to get a Content-Disposition mime header for the text/plain? Or so you want to do what sip has done, and permit all the mime headers in the outer message? Paul Ben Campbell wrote: > Adam Roach wrote: > >> hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] writes: >> >> >>> text/plain does not tell you there is a file attached. I believe it >>> has its own mime type. >> >> >> >> Errmm... no. The mime type doesn't indicate anything about whether >> the content is supposed to be rendered to the user or saved to a >> file. What you're thinking of is Content-Disposition. >> >> http://www.ietf.org/rfc/rfc2183.txt >> >> So, if you wanted to hint that a text/plain payload should be saved >> instead of rendered, I would submit that adding a Content-Disposition >> header to MSRP would achieve the effect you want. > > > Use of content-disposition is interesting, for the reason you mention, > that is to suggest how to render a particular message. I am certainly > open to allowing it in an MSRP message. > > But to head off any proposal of saying we should use this to label the > purpose of an entire _session, I think if we were going to go so far as > to carry content-disposition in the SDP, we could come up with something > both syntactically simpler and better fitting the semantic. > > >> >> /a >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 16:52:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23424; Tue, 11 Nov 2003 16:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgRa-0002kV-00; Tue, 11 Nov 2003 16:53:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJgRZ-0002kS-00; Tue, 11 Nov 2003 16:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgRZ-0000P4-Rn; Tue, 11 Nov 2003 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgQu-0000OR-1Q for simple@optimus.ietf.org; Tue, 11 Nov 2003 16:52:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23396 for ; Tue, 11 Nov 2003 16:52:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgQr-0002jl-00 for simple@ietf.org; Tue, 11 Nov 2003 16:52:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJgQr-0002jG-00 for simple@ietf.org; Tue, 11 Nov 2003 16:52:17 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 13:55:10 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABLpTDM021666; Tue, 11 Nov 2003 16:51:29 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-116.cisco.com [10.86.242.116]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX32894; Tue, 11 Nov 2003 16:51:28 -0500 (EST) Message-ID: <3FB159E0.9040901@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> <3FB10709.5050403@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 16:51:28 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Paul Kyzivat wrote: > >> I agree that retransmission over the same connection is useless and >> shouldn't be attempted. The issue is retransmission of messages >> pending on the old session when switching to a replacement session. >> That situation can arise if for instance a relay crashes. In that case >> the endpoint may well recover by establishing a new session and >> retransmitting any messages not confirmed on the old one. > > > OK, so to clarify the bounderies of this discussion, we do not think > that retransmission within a particular session is useful. This implies > that duplicate suppression _within_ a session is not particularly > interesting for its on sake. Do the active participants in this > conversation agree with this point? Yes. > We _are_ however, concerned about how an implementation might _resume_ a > session that has died for whatever reason. By _resume_, I mean create a > new (and unrelated at the protocol level) session that continues the > conversation. In this case, an implementation might choose to re-send > content for which receiption on the previous session could not be > confirmed. If this occurs, it may be interesting to have a cross-session > duplicate suppression mechanism. There is still open discussion on > whether this is needed at all, and if so, should it be required or > optional. We pretty much agree that if we were to do something like > this, it would involve TR-ID, but there is still open discussion on how > strong of requirements we would need for uniqueness, and remembering > past values. Do the active participants in this conversation agree that > this is the current state of the controversy? Yes. >> Of course Hisham is right that it is possible to leave the decision to >> retransmit to the user of the application. This has a couple of problems: >> - the end user presumably doesn't have access to tools for suppressing >> duplicates. So in cases where the old message had been process but the >> response not delivered this will result in a duplicate message. This >> can be mitigated somewhat by clarifying conversation between the users >> at the two ends. >> >> - automata at one end or the other will be further limited. They are >> likely to be less tolerant of problems and less able to mitigate the >> problems via informal communication. >> > > I would hope that automata would be designed so that duplicates cause no > harm--but I guess it is hard to guarantee that. I must also point out > that our primary use case is delivering messages to humans. While we do > not prohibit automata, we have generally not included requirements that > are specific to automata processing. In the case of automata that know they are talking to other automata I agree with you. I was thinking of the case where one participant is human and another is an automaton. The automaton could be either the sender or the recipient. An example might be a relay the is acting as a recorder. Another might be a chat conference mixer that is trying to ensure that everybody in the conference hears everything that is said. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 16:53:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23440 for ; Tue, 11 Nov 2003 16:53:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgRg-0000TQ-8P for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 16:53:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABLr8ot001814 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 16:53:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgRg-0000R4-0r for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 16:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23424; Tue, 11 Nov 2003 16:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgRa-0002kV-00; Tue, 11 Nov 2003 16:53:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJgRZ-0002kS-00; Tue, 11 Nov 2003 16:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgRZ-0000P4-Rn; Tue, 11 Nov 2003 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgQu-0000OR-1Q for simple@optimus.ietf.org; Tue, 11 Nov 2003 16:52:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23396 for ; Tue, 11 Nov 2003 16:52:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgQr-0002jl-00 for simple@ietf.org; Tue, 11 Nov 2003 16:52:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AJgQr-0002jG-00 for simple@ietf.org; Tue, 11 Nov 2003 16:52:17 -0500 Received: from cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2003 13:55:10 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABLpTDM021666; Tue, 11 Nov 2003 16:51:29 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-116.cisco.com [10.86.242.116]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX32894; Tue, 11 Nov 2003 16:51:28 -0500 (EST) Message-ID: <3FB159E0.9040901@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> <3FB10709.5050403@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 16:51:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Paul Kyzivat wrote: > >> I agree that retransmission over the same connection is useless and >> shouldn't be attempted. The issue is retransmission of messages >> pending on the old session when switching to a replacement session. >> That situation can arise if for instance a relay crashes. In that case >> the endpoint may well recover by establishing a new session and >> retransmitting any messages not confirmed on the old one. > > > OK, so to clarify the bounderies of this discussion, we do not think > that retransmission within a particular session is useful. This implies > that duplicate suppression _within_ a session is not particularly > interesting for its on sake. Do the active participants in this > conversation agree with this point? Yes. > We _are_ however, concerned about how an implementation might _resume_ a > session that has died for whatever reason. By _resume_, I mean create a > new (and unrelated at the protocol level) session that continues the > conversation. In this case, an implementation might choose to re-send > content for which receiption on the previous session could not be > confirmed. If this occurs, it may be interesting to have a cross-session > duplicate suppression mechanism. There is still open discussion on > whether this is needed at all, and if so, should it be required or > optional. We pretty much agree that if we were to do something like > this, it would involve TR-ID, but there is still open discussion on how > strong of requirements we would need for uniqueness, and remembering > past values. Do the active participants in this conversation agree that > this is the current state of the controversy? Yes. >> Of course Hisham is right that it is possible to leave the decision to >> retransmit to the user of the application. This has a couple of problems: >> - the end user presumably doesn't have access to tools for suppressing >> duplicates. So in cases where the old message had been process but the >> response not delivered this will result in a duplicate message. This >> can be mitigated somewhat by clarifying conversation between the users >> at the two ends. >> >> - automata at one end or the other will be further limited. They are >> likely to be less tolerant of problems and less able to mitigate the >> problems via informal communication. >> > > I would hope that automata would be designed so that duplicates cause no > harm--but I guess it is hard to guarantee that. I must also point out > that our primary use case is delivering messages to humans. While we do > not prohibit automata, we have generally not included requirements that > are specific to automata processing. In the case of automata that know they are talking to other automata I agree with you. I was thinking of the case where one participant is human and another is an automaton. The automaton could be either the sender or the recipient. An example might be a relay the is acting as a recorder. Another might be a chat conference mixer that is trying to ensure that everybody in the conference hears everything that is said. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 17:12:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24267; Tue, 11 Nov 2003 17:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgkv-00036a-00; Tue, 11 Nov 2003 17:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJgku-00036X-00; Tue, 11 Nov 2003 17:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgkv-0002Vo-Ck; Tue, 11 Nov 2003 17:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgkW-0002Uw-4R for simple@optimus.ietf.org; Tue, 11 Nov 2003 17:12:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24246 for ; Tue, 11 Nov 2003 17:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgkT-000367-00 for simple@ietf.org; Tue, 11 Nov 2003 17:12:33 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJgkS-00035N-00 for simple@ietf.org; Tue, 11 Nov 2003 17:12:33 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hABMC1Gd018064; Tue, 11 Nov 2003 16:12:01 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 16:12:02 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865F3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Aki Niemi'" , Ben Campbell Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on message-sessions-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 16:12:01 -0600 At the risk of beating a dead horse even more: I wasn't trying to make the point that MSRP should never be used for file transfer (although the purist in me still believes this to be "correct"). My point was that if you were going to initiate "a specific session" for file transfer and file transfer only (that is, no instant messages, just file transfer) as your mail seemed to be advocating, then you *are* using the wrong protocol. More succinctly: there is no valid use case for labeling a session "file transfer only." /a > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Tuesday, November 11, 2003 13:22 > To: ext Ben Campbell > Cc: ext Adam Roach; 'hisham.khartabil@nokia.com'; simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 > > > Hi, > > Perhaps I should also clarify my position. Clearly, if you > are going to > just do file transfer, there is no sense at all to start to develop > something else but to use FTP. > > But this is not the case here. We are developing MSRP to > enable sending > messages in a session, negotiating this in SIP/SDP, and have tools to > invoke relays for these sessions. > > Now, it is also possible *and* useful to send files, or things other > than text/plain, in this session - at which point it becomes "file > transfer". Please explain why this is bad practice just because IETF > already has another protocol to do "file transfer"? > > It's not like we are re-developing TCP here. If we were, I'd > share your > concerns. As I understand it, in the hour-glass model of Internet, > multiple application layer protocols that may even overlap in > functionality is not a bad thing. > > Cheers, > Aki > > ext Ben Campbell wrote: > > From section 5.1: > > > > "An analysis of whether it makes sense to do this [file transfer or > > sending very large content], rather than sending such > content over FTP, > > HTTP, or some other such protocol, is beyond the scope of > this document." > > > > I originally took (and still agree with) Adam's position, > but that is > > clearly not the consensus of this group. (If I am incorrect in that > > belief, I would love to hear it as I could remove quite a > bit of text.) > > > > > > Aki Niemi wrote: > > > >> > >> > >> ext Adam Roach wrote: > >> > >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: > >>> > >>> > >>>> These are somewhat orthogonal aspects of a message > session. It is > >>>> probably useful to label a specific session as e.g., > file-transfer > >>> > >>> > >>> > >>> > >>> Yes. You do this by using port 21. If you know a priori that all > >>> you are going to do is transfer files, the IETF has already > >>> defined a file transfer protocol. > >> > >> > >> > >> Right. And if you know a priori that all you are going to > do is chat > >> with the other party, then just use IRC. Great, we're done. > >> > >> Thanks, > >> Aki > >> > >> > >>> /a > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 17:13:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24302 for ; Tue, 11 Nov 2003 17:13:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgkz-0002Xo-5p for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 17:13:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABMD5RS009774 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 17:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgkz-0002XZ-2U for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 17:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24267; Tue, 11 Nov 2003 17:12:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgkv-00036a-00; Tue, 11 Nov 2003 17:13:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJgku-00036X-00; Tue, 11 Nov 2003 17:13:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgkv-0002Vo-Ck; Tue, 11 Nov 2003 17:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJgkW-0002Uw-4R for simple@optimus.ietf.org; Tue, 11 Nov 2003 17:12:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24246 for ; Tue, 11 Nov 2003 17:12:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJgkT-000367-00 for simple@ietf.org; Tue, 11 Nov 2003 17:12:33 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AJgkS-00035N-00 for simple@ietf.org; Tue, 11 Nov 2003 17:12:33 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hABMC1Gd018064; Tue, 11 Nov 2003 16:12:01 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Nov 2003 16:12:02 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865F3@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Aki Niemi'" , Ben Campbell Cc: Adam Roach , "'hisham.khartabil@nokia.com'" , simple@ietf.org Subject: RE: [Simple] Comments on message-sessions-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 16:12:01 -0600 At the risk of beating a dead horse even more: I wasn't trying to make the point that MSRP should never be used for file transfer (although the purist in me still believes this to be "correct"). My point was that if you were going to initiate "a specific session" for file transfer and file transfer only (that is, no instant messages, just file transfer) as your mail seemed to be advocating, then you *are* using the wrong protocol. More succinctly: there is no valid use case for labeling a session "file transfer only." /a > -----Original Message----- > From: Aki Niemi [mailto:aki.niemi@nokia.com] > Sent: Tuesday, November 11, 2003 13:22 > To: ext Ben Campbell > Cc: ext Adam Roach; 'hisham.khartabil@nokia.com'; simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 > > > Hi, > > Perhaps I should also clarify my position. Clearly, if you > are going to > just do file transfer, there is no sense at all to start to develop > something else but to use FTP. > > But this is not the case here. We are developing MSRP to > enable sending > messages in a session, negotiating this in SIP/SDP, and have tools to > invoke relays for these sessions. > > Now, it is also possible *and* useful to send files, or things other > than text/plain, in this session - at which point it becomes "file > transfer". Please explain why this is bad practice just because IETF > already has another protocol to do "file transfer"? > > It's not like we are re-developing TCP here. If we were, I'd > share your > concerns. As I understand it, in the hour-glass model of Internet, > multiple application layer protocols that may even overlap in > functionality is not a bad thing. > > Cheers, > Aki > > ext Ben Campbell wrote: > > From section 5.1: > > > > "An analysis of whether it makes sense to do this [file transfer or > > sending very large content], rather than sending such > content over FTP, > > HTTP, or some other such protocol, is beyond the scope of > this document." > > > > I originally took (and still agree with) Adam's position, > but that is > > clearly not the consensus of this group. (If I am incorrect in that > > belief, I would love to hear it as I could remove quite a > bit of text.) > > > > > > Aki Niemi wrote: > > > >> > >> > >> ext Adam Roach wrote: > >> > >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: > >>> > >>> > >>>> These are somewhat orthogonal aspects of a message > session. It is > >>>> probably useful to label a specific session as e.g., > file-transfer > >>> > >>> > >>> > >>> > >>> Yes. You do this by using port 21. If you know a priori that all > >>> you are going to do is transfer files, the IETF has already > >>> defined a file transfer protocol. > >> > >> > >> > >> Right. And if you know a priori that all you are going to > do is chat > >> with the other party, then just use IRC. Great, we're done. > >> > >> Thanks, > >> Aki > >> > >> > >>> /a > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 17:29:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25167; Tue, 11 Nov 2003 17:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJh1O-0003TB-00; Tue, 11 Nov 2003 17:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJh1N-0003T8-00; Tue, 11 Nov 2003 17:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJh1M-0003mQ-R1; Tue, 11 Nov 2003 17:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJh11-0003ln-Vl for simple@optimus.ietf.org; Tue, 11 Nov 2003 17:29:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25140 for ; Tue, 11 Nov 2003 17:29:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJh0z-0003Sh-00 for simple@ietf.org; Tue, 11 Nov 2003 17:29:37 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJh0x-0003SP-00 for simple@ietf.org; Tue, 11 Nov 2003 17:29:35 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Nov 2003 14:31:05 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABMT2w5001860; Tue, 11 Nov 2003 14:29:03 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-20.cisco.com [10.86.240.20]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX36406; Tue, 11 Nov 2003 17:29:02 -0500 (EST) Message-ID: <3FB162AB.1040503@cisco.com> 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: Aki Niemi CC: ext Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> <3FB10709.5050403@dynamicsoft.com> <3FB11735.3090600@nokia.com> Content-Type: multipart/mixed; boundary="------------010004080703080706050302" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 17:28:59 -0500 This is a multi-part message in MIME format. --------------010004080703080706050302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > I think the first thing to understand is how the end point deals with a > failing session. I agree. > If it tears down the session (i.e., a SIP BYE) in case > messages time out or a connection is dropped, then resuming a session > under these conditions is identical to resuming any old message session. I had in mind something slightly less drastic than BYE. I had in mind a reinvite that establishes a replacement media session. This seems to be the right thing to do if the signaling channel is functional but the media channel is broken. If you reestablish the signaling path as well it is more difficult to establish a correlation between the old and new media sessions. I discussed this somewhat earlier in this thread - copy of message attached. But there wasn't any discussion on most of that - just this part about message retransmission has been discussed. I think the whole process of recovering from errors (e.g. media errors) is worthy of more specification in sip/sipping as well as in simple. > This suggests some sort of support for message threads, or session > identifiers, and as you also hint, goes beyond what the TR-ID is > supposed to do. Perhaps. Paul --------------010004080703080706050302 Content-Type: message/rfc822; name="mailbox-message://pkyzivat@cannon.cisco.com/cisco/SIP#71463691" Content-Disposition: inline; filename="mailbox-message://pkyzivat@cannon.cisco.com/cisco/SIP#71463691" Return-Path: Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18803; Wed, 5 Nov 2003 14:21:02 -0500 (EST) Received: from ietf.org (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2003 11:25:32 -0800 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JKumU007542; Wed, 5 Nov 2003 11:20:57 -0800 (PST) Received: from optimus.ietf.org ([132.151.6.22]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id hA5JLKrj029248; Wed, 5 Nov 2003 11:21:21 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTCE-0005hN-CW; Wed, 05 Nov 2003 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTBE-0005ew-5R for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:19:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17983 for ; Wed, 5 Nov 2003 14:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000164-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000160-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:19:00 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JIKDd008955; Wed, 5 Nov 2003 11:18:20 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18458; Wed, 5 Nov 2003 14:18:19 -0500 (EST) Message-ID: <3FA94CFB.70102@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - reinvite behavior References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:18:19 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 6: > - Reference to RFC 3264 is probably needed here. > - I had trouble figuring out how to send a second offer after the > first offer/answer exchange, for example to add a new mime type > of to add a new session. How does the new offer look like? Even before discussing that, it is important to be clear what an offer/answer that doesn't change *anything* looks like. For instance this might occur when attempting to do a session timer refresh, or when there is another media session (e.g. voice) that is being changed but this one isn't. Normally, you expect that the last SDP can be exchanged without change. This works pretty simply for RTP and UDP. But it has presented some issues in comedia, and may do so here as well. The question is how to decide if this is a request to tear down the old session and build a new one, or simply to leave the old one alone. For instance, suppose I am the visitor in the current session, and I have experienced a timeout - I sent something and got no response. I would like to try to remedy the situation. But I still need to be the visitor. So what can I do? I can send a reinvite. It will presumably look like my last one. If the other end is still present and receives the reinvite, I perhaps would like him to tear down the existing stream and offer me a chance to visit a new one. > Do we need to include the session attribute carrying the session URI again? > What do we set the direction attribute to, if set at all in the second offer? I think the answer should be something like: If the visitor initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with a=direction:active, even if direction:both had been used previously. Then if the answerer also prefers to continue with the existing session, it should answer with direction:passive and include the old session URI. Receipt of an answer with the old session URI is a signal to the offerer to continue using the existing session. OTOH, if the answerer prefers to switch to a new media session, it should respond with a new session URI. If the host initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with direction:passive and the old session URI. Then if the answerer prefers also prefers to continue with the existing session, it should answer with direction:active, and just continue using the old session. If the answerer prefers to switch to a new media session it can either accept this as just mentioned or refuse it by setting the port to zero. Then it can initiate a new offer/answer cycle. If the host initiates a new offer/answer cycle and wants to switch to a new media session, it may send an offer with a new session URI and with a direction of either passive or both. Either way is clear. All actions are as if starting from scratch. If the visitor initiates a new offer/answer cycle and wants to switch to a new media session, and if it is capable of acting as host, it can do as in the prior paragraph. If it cannot, then the best it can do is to send an offer with a port of zero to terminate the existing session. It can then then do yet another offer/answer to establish a new session. Or, it can combine the two steps - setting the port to zero for the existing session but proposing a new 2nd session in the same offer. [Is more needed to cover the two relay case???] A reinvite to make a change like adding a new mime type, that doesn't require changing the connections, can be the same as above, but changing the attributes appropriately. However, just as there are rules about changing codecs in reinvites, there probably should be rules about changing supported mime types in existing MSRP sessions. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --------------010004080703080706050302-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 17:30:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25190 for ; Tue, 11 Nov 2003 17:30:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJh1R-0003nC-QS for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 17:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABMU5Kh014576 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 17:30:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJh1R-0003n1-MR for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 17:30:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25167; Tue, 11 Nov 2003 17:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJh1O-0003TB-00; Tue, 11 Nov 2003 17:30:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJh1N-0003T8-00; Tue, 11 Nov 2003 17:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJh1M-0003mQ-R1; Tue, 11 Nov 2003 17:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJh11-0003ln-Vl for simple@optimus.ietf.org; Tue, 11 Nov 2003 17:29:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25140 for ; Tue, 11 Nov 2003 17:29:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJh0z-0003Sh-00 for simple@ietf.org; Tue, 11 Nov 2003 17:29:37 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJh0x-0003SP-00 for simple@ietf.org; Tue, 11 Nov 2003 17:29:35 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 11 Nov 2003 14:31:05 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hABMT2w5001860; Tue, 11 Nov 2003 14:29:03 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-20.cisco.com [10.86.240.20]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX36406; Tue, 11 Nov 2003 17:29:02 -0500 (EST) Message-ID: <3FB162AB.1040503@cisco.com> 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: Aki Niemi CC: ext Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017973AB@esebe019.ntc.nokia.com> <3FB04128.2020103@dynamicsoft.com> <3FB102F2.8050405@cisco.com> <3FB10709.5050403@dynamicsoft.com> <3FB11735.3090600@nokia.com> Content-Type: multipart/mixed; boundary="------------010004080703080706050302" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 11 Nov 2003 17:28:59 -0500 This is a multi-part message in MIME format. --------------010004080703080706050302 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Aki Niemi wrote: > > I think the first thing to understand is how the end point deals with a > failing session. I agree. > If it tears down the session (i.e., a SIP BYE) in case > messages time out or a connection is dropped, then resuming a session > under these conditions is identical to resuming any old message session. I had in mind something slightly less drastic than BYE. I had in mind a reinvite that establishes a replacement media session. This seems to be the right thing to do if the signaling channel is functional but the media channel is broken. If you reestablish the signaling path as well it is more difficult to establish a correlation between the old and new media sessions. I discussed this somewhat earlier in this thread - copy of message attached. But there wasn't any discussion on most of that - just this part about message retransmission has been discussed. I think the whole process of recovering from errors (e.g. media errors) is worthy of more specification in sip/sipping as well as in simple. > This suggests some sort of support for message threads, or session > identifiers, and as you also hint, goes beyond what the TR-ID is > supposed to do. Perhaps. Paul --------------010004080703080706050302 Content-Type: message/rfc822; name="mailbox-message://pkyzivat@cannon.cisco.com/cisco/SIP#71463691" Content-Disposition: inline; filename="mailbox-message://pkyzivat@cannon.cisco.com/cisco/SIP#71463691" Return-Path: Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18803; Wed, 5 Nov 2003 14:21:02 -0500 (EST) Received: from ietf.org (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2003 11:25:32 -0800 Received: from sj-inbound-4.cisco.com (sj-inbound-4.cisco.com [128.107.250.145]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JKumU007542; Wed, 5 Nov 2003 11:20:57 -0800 (PST) Received: from optimus.ietf.org ([132.151.6.22]) by sj-inbound-4.cisco.com (8.12.10/8.11.2) with ESMTP id hA5JLKrj029248; Wed, 5 Nov 2003 11:21:21 -0800 (PST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTCE-0005hN-CW; Wed, 05 Nov 2003 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHTBE-0005ew-5R for simple@optimus.ietf.org; Wed, 05 Nov 2003 14:19:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17983 for ; Wed, 5 Nov 2003 14:18:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000164-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHTBB-000160-00 for simple@ietf.org; Wed, 05 Nov 2003 14:18:57 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2003 11:19:00 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5JIKDd008955; Wed, 5 Nov 2003 11:18:20 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT18458; Wed, 5 Nov 2003 14:18:19 -0500 (EST) Message-ID: <3FA94CFB.70102@cisco.com> 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: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - reinvite behavior References: <2038BCC78B1AD641891A0D1AE133DBB701797386@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 05 Nov 2003 14:18:19 -0500 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > - Section 6: > - Reference to RFC 3264 is probably needed here. > - I had trouble figuring out how to send a second offer after the > first offer/answer exchange, for example to add a new mime type > of to add a new session. How does the new offer look like? Even before discussing that, it is important to be clear what an offer/answer that doesn't change *anything* looks like. For instance this might occur when attempting to do a session timer refresh, or when there is another media session (e.g. voice) that is being changed but this one isn't. Normally, you expect that the last SDP can be exchanged without change. This works pretty simply for RTP and UDP. But it has presented some issues in comedia, and may do so here as well. The question is how to decide if this is a request to tear down the old session and build a new one, or simply to leave the old one alone. For instance, suppose I am the visitor in the current session, and I have experienced a timeout - I sent something and got no response. I would like to try to remedy the situation. But I still need to be the visitor. So what can I do? I can send a reinvite. It will presumably look like my last one. If the other end is still present and receives the reinvite, I perhaps would like him to tear down the existing stream and offer me a chance to visit a new one. > Do we need to include the session attribute carrying the session URI again? > What do we set the direction attribute to, if set at all in the second offer? I think the answer should be something like: If the visitor initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with a=direction:active, even if direction:both had been used previously. Then if the answerer also prefers to continue with the existing session, it should answer with direction:passive and include the old session URI. Receipt of an answer with the old session URI is a signal to the offerer to continue using the existing session. OTOH, if the answerer prefers to switch to a new media session, it should respond with a new session URI. If the host initiates a new offer/answer and prefers to continue with the existing session, it should send the offer with direction:passive and the old session URI. Then if the answerer prefers also prefers to continue with the existing session, it should answer with direction:active, and just continue using the old session. If the answerer prefers to switch to a new media session it can either accept this as just mentioned or refuse it by setting the port to zero. Then it can initiate a new offer/answer cycle. If the host initiates a new offer/answer cycle and wants to switch to a new media session, it may send an offer with a new session URI and with a direction of either passive or both. Either way is clear. All actions are as if starting from scratch. If the visitor initiates a new offer/answer cycle and wants to switch to a new media session, and if it is capable of acting as host, it can do as in the prior paragraph. If it cannot, then the best it can do is to send an offer with a port of zero to terminate the existing session. It can then then do yet another offer/answer to establish a new session. Or, it can combine the two steps - setting the port to zero for the existing session but proposing a new 2nd session in the same offer. [Is more needed to cover the two relay case???] A reinvite to make a change like adding a new mime type, that doesn't require changing the connections, can be the same as above, but changing the attributes appropriately. However, just as there are rules about changing codecs in reinvites, there probably should be rules about changing supported mime types in existing MSRP sessions. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --------------010004080703080706050302-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 19:53:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01439; Tue, 11 Nov 2003 19:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjGo-0005Zo-00; Tue, 11 Nov 2003 19:54:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJjGo-0005Zl-00; Tue, 11 Nov 2003 19:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjGk-0006xa-3Q; Tue, 11 Nov 2003 19:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjGe-0006wO-Uq for simple@optimus.ietf.org; Tue, 11 Nov 2003 19:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01390 for ; Tue, 11 Nov 2003 19:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjGc-0005Z1-00 for simple@ietf.org; Tue, 11 Nov 2003 19:53:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJjGc-0005Yt-00 for simple@ietf.org; Tue, 11 Nov 2003 19:53:54 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC0rss03049 for ; Wed, 12 Nov 2003 02:53:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 02:53:53 +0200 Received: from nokia.com ([10.162.13.83]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 02:53:53 +0200 Message-ID: <3FB184A0.3030000@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on draft-isomaki-simple-xcap-publish-usage References: <3FAFB77F.2080903@dynamicsoft.com> In-Reply-To: <3FAFB77F.2080903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2003 00:53:53.0272 (UTC) FILETIME=[7178A780:01C3A8B7] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 02:53:52 +0200 Content-Transfer-Encoding: 7bit Hi, Inline. ext Jonathan Rosenberg wrote: > I have a few comments on: > > http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usage-00.txt > > > > I think this is a good draft, and is the appropriate way to solve > this problem. > > My main comment is that I think we need to be very clear on the > difference between this mechanism and SIP PUBLISH. I know we went > through a lot of this on the list some time back. In particular, one > could presumably use PUBLISH with an infinitely long Expires header > field, and achieve a near "hard state" publication. This doesn't necessarily work. In PUBLISH, the expiration is related to the composer's desire to clear up dead publications vs. its desire to throttle publication refreshes. It's just like how a registrar manages address bindings - the published state might be valid forever, but needs periodic refreshes. In practice, the ESC can't know whether the EPAs intention is to hog resources, or publish hard state. > I think the real > difference is that this is provisioned data that describes the > presentity independent of any particular device, for which we require > any possible device, and even web pages and provisioning systems, to > manipulate. PUBLISH is really focused on allowing a particular PUA > to publish its view of the presentity, separate from other views > published by other PUAs. As such, manipulating presence hard state > from many different sources using PUBLISH is not easy, as the Etags > would need to be shared. There is no obvious mechanism for that. Yes, this is an intentional limitation of PUBLISH. There is no way to query the full "raw" set of publications and the etags associated with them. > Also, there will be a clear need to do a pure fetch of the hard state > presence data, a feature we don't have with PUBLISH. I think the > draft should clearly enumerate these problems, and provide guidance > on when to use this mechanism, vs. PUBLISH. I agree. it might also be a good idea to include a bit more about this in the PUBLISH draft. > Regarding the open issue: > >> Publishing of external content: how to publish external content >> (e.g., an icon) referenced from PIDF in case of the XCAP based >> publishing? Is the content transported separately from the PIDF >> formatted document so that the PIDF includes only a reference to >> the separately transported content and the compositor is capable >> for linking the information together? This might require that the >> compositor is able to change the content of the reference. > > > This is more of a pidf question, I think. The current leaning with > PIDF would be to include such icons by reference. The document stored > in the xcap server would include such a reference. That reference > would presumably be an HTTP URI that can dreference content on the > same server. The user would need to have a directory where they are > permitted to upload content. This would work. I think the tricky part is really inline content, and using CIDs (assuming that's a valid option for including non-XML information in PIDF). Cheers, Aki > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 19:54:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01503 for ; Tue, 11 Nov 2003 19:54:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjGr-0006yf-Tl for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 19:54:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC0s9nN026816 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 19:54:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjGr-0006yR-Q8 for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 19:54:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01439; Tue, 11 Nov 2003 19:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjGo-0005Zo-00; Tue, 11 Nov 2003 19:54:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJjGo-0005Zl-00; Tue, 11 Nov 2003 19:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjGk-0006xa-3Q; Tue, 11 Nov 2003 19:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjGe-0006wO-Uq for simple@optimus.ietf.org; Tue, 11 Nov 2003 19:53:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01390 for ; Tue, 11 Nov 2003 19:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjGc-0005Z1-00 for simple@ietf.org; Tue, 11 Nov 2003 19:53:55 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJjGc-0005Yt-00 for simple@ietf.org; Tue, 11 Nov 2003 19:53:54 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC0rss03049 for ; Wed, 12 Nov 2003 02:53:54 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 02:53:53 +0200 Received: from nokia.com ([10.162.13.83]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 02:53:53 +0200 Message-ID: <3FB184A0.3030000@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on draft-isomaki-simple-xcap-publish-usage References: <3FAFB77F.2080903@dynamicsoft.com> In-Reply-To: <3FAFB77F.2080903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2003 00:53:53.0272 (UTC) FILETIME=[7178A780:01C3A8B7] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 02:53:52 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Inline. ext Jonathan Rosenberg wrote: > I have a few comments on: > > http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap-publish-usage-00.txt > > > > I think this is a good draft, and is the appropriate way to solve > this problem. > > My main comment is that I think we need to be very clear on the > difference between this mechanism and SIP PUBLISH. I know we went > through a lot of this on the list some time back. In particular, one > could presumably use PUBLISH with an infinitely long Expires header > field, and achieve a near "hard state" publication. This doesn't necessarily work. In PUBLISH, the expiration is related to the composer's desire to clear up dead publications vs. its desire to throttle publication refreshes. It's just like how a registrar manages address bindings - the published state might be valid forever, but needs periodic refreshes. In practice, the ESC can't know whether the EPAs intention is to hog resources, or publish hard state. > I think the real > difference is that this is provisioned data that describes the > presentity independent of any particular device, for which we require > any possible device, and even web pages and provisioning systems, to > manipulate. PUBLISH is really focused on allowing a particular PUA > to publish its view of the presentity, separate from other views > published by other PUAs. As such, manipulating presence hard state > from many different sources using PUBLISH is not easy, as the Etags > would need to be shared. There is no obvious mechanism for that. Yes, this is an intentional limitation of PUBLISH. There is no way to query the full "raw" set of publications and the etags associated with them. > Also, there will be a clear need to do a pure fetch of the hard state > presence data, a feature we don't have with PUBLISH. I think the > draft should clearly enumerate these problems, and provide guidance > on when to use this mechanism, vs. PUBLISH. I agree. it might also be a good idea to include a bit more about this in the PUBLISH draft. > Regarding the open issue: > >> Publishing of external content: how to publish external content >> (e.g., an icon) referenced from PIDF in case of the XCAP based >> publishing? Is the content transported separately from the PIDF >> formatted document so that the PIDF includes only a reference to >> the separately transported content and the compositor is capable >> for linking the information together? This might require that the >> compositor is able to change the content of the reference. > > > This is more of a pidf question, I think. The current leaning with > PIDF would be to include such icons by reference. The document stored > in the xcap server would include such a reference. That reference > would presumably be an HTTP URI that can dreference content on the > same server. The user would need to have a directory where they are > permitted to upload content. This would work. I think the tricky part is really inline content, and using CIDs (assuming that's a valid option for including non-XML information in PIDF). Cheers, Aki > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 20:32:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02974; Tue, 11 Nov 2003 20:32:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjsV-0006GC-00; Tue, 11 Nov 2003 20:33:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJjsU-0006G9-00; Tue, 11 Nov 2003 20:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjsT-0001bh-El; Tue, 11 Nov 2003 20:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjro-0001bB-6n for simple@optimus.ietf.org; Tue, 11 Nov 2003 20:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02963 for ; Tue, 11 Nov 2003 20:32:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjrl-0006Fs-00 for simple@ietf.org; Tue, 11 Nov 2003 20:32:17 -0500 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AJjrl-0006Fp-00 for simple@ietf.org; Tue, 11 Nov 2003 20:32:17 -0500 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 12 Nov 2003 01:34:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <45730E094814E44488F789C1CDED27AE0219B109@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Message Sessions review Thread-Index: AcOovM3LgGD3Hm+mQ1KZwfwD7GZbLw== From: "Chris Boulton" To: , Cc: Content-Transfer-Encoding: base64 Subject: [Simple] Message Sessions review Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 01:32:16 -0000 Content-Transfer-Encoding: base64 QWxsLA0KIA0KUmV2aWV3ZWQgdGhlIGxhdGVzdCByZXZpc29uIGFuZCBpdCBsb29rcyBwcmV0dHkg Z29vZCB0byBtZSA7LSkuICBJIGhhdmUgZ290IGEgZmV3IG1pbm9yIG5pdHMsIEkgYXBvbG9naXNl IGlmIHRoZXNlIGhhdmUgYWxyZWFkeSBiZWVuIHBvaW50ZWQgb3V0LiANCiANClNlY3Rpb24gNS4z IA0KcmVhZHMgLSAnSG93ZXZlciwgdGhlc2Ugc29sdXRpb25zIHByb21pc2VkIHRvIGFkZCBhIGdy ZWF0IGRlYWwgb2YgY29tcGxleGl0eSB0byB0aGUgcHJvdG9jb2wsIHNvIHRoZSB3b3JrIGdyb3Vw IGNob3NlIG5vdCB0byBnbyB0aGF0IHJvdXRlJy4NCiANCnNob3VsZCByZWFkIC0gJ0hvd2V2ZXIs IHRoZXNlIHNvbHV0aW9ucyBwcm9taXNlZCB0byBhZGQgYSBncmVhdCBkZWFsIG9mIGNvbXBsZXhp dHkgdG8gdGhlIHByb3RvY29sLCBzbyB0aGUgd29yayBncm91cCBjaG9zZSBub3QgdG8gdGFrZSB0 aGF0IHJvdXRlLg0KIA0KU2VjdGlvbiA3LjEgcmVhZHMgLSAnSWYgYSB1c2VyaW5mbyBjb21wb25l bnQgZXhpc3RzLCBNVVNUIGJlIGNvbnN0cnVjdGVkIG9ubHkgZnJvbSAidW5yZXNlcnZlZCIgY2hh cmFjdGVycywgdG8gYXZvaWQgYSBuZWVkIGZvciBlc2NhcGUgcHJvY2Vzc2luZycNCiANCnNob3Vs ZCByZWFkIC0gSWYgYSB1c2VyaW5mbyBjb21wb25lbnQgZXhpc3RzLCBpdCBNVVNUIGJlIGNvbnN0 cnVjdGVkIG9ubHkgZnJvbSAidW5yZXNlcnZlZCIgY2hhcmFjdGVycywgdG8gYXZvaWQgYSBuZWVk IGZvciBlc2NhcGUgcHJvY2Vzc2luZy4NCiANClNlY3Rpb24gNy4xLjEgcmVhZHMgLSBBbiBVUkwg d2l0aCBhbiBleHBsaWNpdCBwb3J0IGlzIG5ldmVyIGVxdWl2YWxlbnQgdG8gYW5vdGhlciB3aXRo IG5vIHBvcnQgc3BlY2lmaWVkLg0KIA0Kc2hvdWxkIHJlYWQgLSBBIFVSTCB3aXRoIGFuIGV4cGxp Y2l0IHBvcnQgaXMgbmV2ZXIgZXF1aXZhbGVudCB0byBhIFVSTCB3aXRob3V0IGEgcG9ydCBzcGVj aWZpZWQuDQogDQpTZWN0aW9uIDcuNC42IHJlYWRzIC0gJyBBIE1TUlAgc2Vzc2lvbiBpcyByZXBy ZXNlbnRlZCBieSBzdGF0ZSBhdCB0aGUgaG9zdCBkZXZpY2UuIEFzIG1lbnRpb24gcHJldmlvdXNs eSwgc2Vzc2lvbiBzdGF0ZSBpcyBpZGVudGlmaWVkIGJ5IGFuIE1TUlAgVVJMJy4NCiANCnNob3Vs ZCByZWFkIC0gJyBBbiBNU1JQIHNlc3Npb24gaXMgcmVwcmVzZW50ZWQgYnkgc3RhdGUgYXQgdGhl IGhvc3QgZGV2aWNlLiBBcyBtZW50aW9uZWQgcHJldmlvdXNseSwgc2Vzc2lvbiBzdGF0ZSBpcyBp ZGVudGlmaWVkIGJ5IGFuIE1TUlAgVVJMJy4NCiANClNlY3Rpb24gNy41LjEgcmVhZHMgLSAnSWYg dGhlIHJlbGF5IHdpc2hlcyB0aGUgdmlzaXRpbmcgZW5kcG9pbnQgdG8gY29ubmVjdCBvdmVyIGEg cG9ydCBvdGhlciB0aGFuIHRoZSBNU1JQIHJlbGF5IHdlbGwta25vdyBwb3J0LCBpdCBNVVNUIGV4 cGxpY2l0bHkgYWRkIHRoZSBwb3J0IG51bWJlciB0byB2aXNpdG9yIFVSTCcuDQogDQpzaG91bGQg cmVhZCAtICdJZiB0aGUgcmVsYXkgd2lzaGVzIHRoZSB2aXNpdGluZyBlbmRwb2ludCB0byBjb25u ZWN0IG92ZXIgYSBwb3J0IG90aGVyIHRoYW4gdGhlIE1TUlAgcmVsYXkgd2VsbC1rbm93biBwb3J0 LCBpdCBNVVNUIGV4cGxpY2l0bHkgYWRkIHRoZSBwb3J0IG51bWJlciB0byB2aXNpdG9yIFVSTCcu DQogDQpTZWN0aW9uIDcuNy4xIHJlYWRzIC0gJ1RoZSBCSU5EIG1ldGhvZCBpcyB1c2VkIGJ5IGEg aG9zdCBlbmRwb2ludCB0byBlc3RhYmxpc2ggb3IgcmVmcmVzaA0KICAgc2Vzc2lvbiBzdGF0ZSBh dCBhIGhvc3RpbmcgcmVsYXknLg0KIA0KU2hvdWxkIHdlIGV4cGxpY2l0bHkgaW5jbHVkZSAnVGVy bWluYXRlJyBpbiB0aGlzIGRlc2NyaXB0aW9uIG9yIGlzIGl0IGVub3VnaCB0byBjb25zaWRlciBp dCBhIHJlZnJlc2ggKHdpdGggMCBFeHBpcnkpLg0KIA0KIA0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 20:33:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03019 for ; Tue, 11 Nov 2003 20:33:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjsY-0001cj-IC for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 20:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC1X6ee006235 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 20:33:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjsY-0001cU-Di for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 20:33:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02974; Tue, 11 Nov 2003 20:32:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjsV-0006GC-00; Tue, 11 Nov 2003 20:33:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJjsU-0006G9-00; Tue, 11 Nov 2003 20:33:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjsT-0001bh-El; Tue, 11 Nov 2003 20:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJjro-0001bB-6n for simple@optimus.ietf.org; Tue, 11 Nov 2003 20:32:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02963 for ; Tue, 11 Nov 2003 20:32:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJjrl-0006Fs-00 for simple@ietf.org; Tue, 11 Nov 2003 20:32:17 -0500 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AJjrl-0006Fp-00 for simple@ietf.org; Tue, 11 Nov 2003 20:32:17 -0500 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Wed, 12 Nov 2003 01:34:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Message-ID: <45730E094814E44488F789C1CDED27AE0219B109@gbnewp0758m.eu.ubiquity.net> Thread-Topic: Message Sessions review Thread-Index: AcOovM3LgGD3Hm+mQ1KZwfwD7GZbLw== From: "Chris Boulton" To: , Cc: Content-Transfer-Encoding: base64 Subject: [Simple] Message Sessions review Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 01:32:16 -0000 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWxsLA0KIA0KUmV2aWV3ZWQgdGhlIGxhdGVzdCByZXZpc29uIGFuZCBpdCBsb29rcyBwcmV0dHkg Z29vZCB0byBtZSA7LSkuICBJIGhhdmUgZ290IGEgZmV3IG1pbm9yIG5pdHMsIEkgYXBvbG9naXNl IGlmIHRoZXNlIGhhdmUgYWxyZWFkeSBiZWVuIHBvaW50ZWQgb3V0LiANCiANClNlY3Rpb24gNS4z IA0KcmVhZHMgLSAnSG93ZXZlciwgdGhlc2Ugc29sdXRpb25zIHByb21pc2VkIHRvIGFkZCBhIGdy ZWF0IGRlYWwgb2YgY29tcGxleGl0eSB0byB0aGUgcHJvdG9jb2wsIHNvIHRoZSB3b3JrIGdyb3Vw IGNob3NlIG5vdCB0byBnbyB0aGF0IHJvdXRlJy4NCiANCnNob3VsZCByZWFkIC0gJ0hvd2V2ZXIs IHRoZXNlIHNvbHV0aW9ucyBwcm9taXNlZCB0byBhZGQgYSBncmVhdCBkZWFsIG9mIGNvbXBsZXhp dHkgdG8gdGhlIHByb3RvY29sLCBzbyB0aGUgd29yayBncm91cCBjaG9zZSBub3QgdG8gdGFrZSB0 aGF0IHJvdXRlLg0KIA0KU2VjdGlvbiA3LjEgcmVhZHMgLSAnSWYgYSB1c2VyaW5mbyBjb21wb25l bnQgZXhpc3RzLCBNVVNUIGJlIGNvbnN0cnVjdGVkIG9ubHkgZnJvbSAidW5yZXNlcnZlZCIgY2hh cmFjdGVycywgdG8gYXZvaWQgYSBuZWVkIGZvciBlc2NhcGUgcHJvY2Vzc2luZycNCiANCnNob3Vs ZCByZWFkIC0gSWYgYSB1c2VyaW5mbyBjb21wb25lbnQgZXhpc3RzLCBpdCBNVVNUIGJlIGNvbnN0 cnVjdGVkIG9ubHkgZnJvbSAidW5yZXNlcnZlZCIgY2hhcmFjdGVycywgdG8gYXZvaWQgYSBuZWVk IGZvciBlc2NhcGUgcHJvY2Vzc2luZy4NCiANClNlY3Rpb24gNy4xLjEgcmVhZHMgLSBBbiBVUkwg d2l0aCBhbiBleHBsaWNpdCBwb3J0IGlzIG5ldmVyIGVxdWl2YWxlbnQgdG8gYW5vdGhlciB3aXRo IG5vIHBvcnQgc3BlY2lmaWVkLg0KIA0Kc2hvdWxkIHJlYWQgLSBBIFVSTCB3aXRoIGFuIGV4cGxp Y2l0IHBvcnQgaXMgbmV2ZXIgZXF1aXZhbGVudCB0byBhIFVSTCB3aXRob3V0IGEgcG9ydCBzcGVj aWZpZWQuDQogDQpTZWN0aW9uIDcuNC42IHJlYWRzIC0gJyBBIE1TUlAgc2Vzc2lvbiBpcyByZXBy ZXNlbnRlZCBieSBzdGF0ZSBhdCB0aGUgaG9zdCBkZXZpY2UuIEFzIG1lbnRpb24gcHJldmlvdXNs eSwgc2Vzc2lvbiBzdGF0ZSBpcyBpZGVudGlmaWVkIGJ5IGFuIE1TUlAgVVJMJy4NCiANCnNob3Vs ZCByZWFkIC0gJyBBbiBNU1JQIHNlc3Npb24gaXMgcmVwcmVzZW50ZWQgYnkgc3RhdGUgYXQgdGhl IGhvc3QgZGV2aWNlLiBBcyBtZW50aW9uZWQgcHJldmlvdXNseSwgc2Vzc2lvbiBzdGF0ZSBpcyBp ZGVudGlmaWVkIGJ5IGFuIE1TUlAgVVJMJy4NCiANClNlY3Rpb24gNy41LjEgcmVhZHMgLSAnSWYg dGhlIHJlbGF5IHdpc2hlcyB0aGUgdmlzaXRpbmcgZW5kcG9pbnQgdG8gY29ubmVjdCBvdmVyIGEg cG9ydCBvdGhlciB0aGFuIHRoZSBNU1JQIHJlbGF5IHdlbGwta25vdyBwb3J0LCBpdCBNVVNUIGV4 cGxpY2l0bHkgYWRkIHRoZSBwb3J0IG51bWJlciB0byB2aXNpdG9yIFVSTCcuDQogDQpzaG91bGQg cmVhZCAtICdJZiB0aGUgcmVsYXkgd2lzaGVzIHRoZSB2aXNpdGluZyBlbmRwb2ludCB0byBjb25u ZWN0IG92ZXIgYSBwb3J0IG90aGVyIHRoYW4gdGhlIE1TUlAgcmVsYXkgd2VsbC1rbm93biBwb3J0 LCBpdCBNVVNUIGV4cGxpY2l0bHkgYWRkIHRoZSBwb3J0IG51bWJlciB0byB2aXNpdG9yIFVSTCcu DQogDQpTZWN0aW9uIDcuNy4xIHJlYWRzIC0gJ1RoZSBCSU5EIG1ldGhvZCBpcyB1c2VkIGJ5IGEg aG9zdCBlbmRwb2ludCB0byBlc3RhYmxpc2ggb3IgcmVmcmVzaA0KICAgc2Vzc2lvbiBzdGF0ZSBh dCBhIGhvc3RpbmcgcmVsYXknLg0KIA0KU2hvdWxkIHdlIGV4cGxpY2l0bHkgaW5jbHVkZSAnVGVy bWluYXRlJyBpbiB0aGlzIGRlc2NyaXB0aW9uIG9yIGlzIGl0IGVub3VnaCB0byBjb25zaWRlciBp dCBhIHJlZnJlc2ggKHdpdGggMCBFeHBpcnkpLg0KIA0KIA0K _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 11 21:49:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05131; Tue, 11 Nov 2003 21:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJl51-0007D7-00; Tue, 11 Nov 2003 21:50:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJl51-0007D4-00; Tue, 11 Nov 2003 21:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJl50-00076y-2I; Tue, 11 Nov 2003 21:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJl4K-00076f-NA for simple@optimus.ietf.org; Tue, 11 Nov 2003 21:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05120 for ; Tue, 11 Nov 2003 21:49:07 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJl4H-0007Cp-00 for simple@ietf.org; Tue, 11 Nov 2003 21:49:17 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJl4G-0007Ch-00 for simple@ietf.org; Tue, 11 Nov 2003 21:49:16 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC2nFB16499 for ; Wed, 12 Nov 2003 04:49:15 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 04:49:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 04:49:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 04:49:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] comments on draft-isomaki-simple-xcap-publish-usage Message-ID: Thread-Topic: [Simple] comments on draft-isomaki-simple-xcap-publish-usage Thread-Index: AcOnpNkdHEbc7bewRXuH5r5x1ExTEABDqY+g To: , X-OriginalArrivalTime: 12 Nov 2003 02:49:14.0447 (UTC) FILETIME=[8ED025F0:01C3A8C7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 04:49:13 +0200 Content-Transfer-Encoding: quoted-printable Hi, Thanks for the comments. See below: > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 10 November, 2003 18:06 > To: Simple WG > Subject: [Simple] comments on draft-isomaki-simple-xcap-publish-usage >=20 >=20 > I have a few comments on: >=20 > http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap- > publish-usage-00.txt >=20 > I think this is a good draft, and is the appropriate way to=20 > solve this=20 > problem. >=20 > My main comment is that I think we need to be very clear on the=20 > difference between this mechanism and SIP PUBLISH. I know we went=20 > through a lot of this on the list some time back. In particular, one=20 > could presumably use PUBLISH with an infinitely long Expires header=20 > field, and achieve a near "hard state" publication. I think the real=20 > difference is that this is provisioned data that describes the=20 > presentity independent of any particular device, for which we require=20 > any possible device, and even web pages and provisioning systems, to=20 > manipulate. PUBLISH is really focused on allowing a particular PUA to=20 > publish its view of the presentity, separate from other views=20 > published by other PUAs. As such, manipulating presence hard state=20 > from many different sources using PUBLISH is not easy, as the Etags=20 > would need to be shared. There is no obvious mechanism for=20 > that. Also,=20 > there will be a clear need to do a pure fetch of the hard state=20 > presence data, a feature we don't have with PUBLISH. I think=20 > the draft=20 > should clearly enumerate these problems, and provide guidance on when=20 > to use this mechanism, vs. PUBLISH. >=20 I think this is a good description on the benefits of XCAP presence = publishing application usage compared to SIP PUBLISH. Aki also provided = some consideration why SIP PUBLISH with infinite expiration might not = work. I agree that all this should be added to the next revision of the = draft. > Regarding the open issue: >=20 > > Publishing of external content: how to publish external content > > (e.g., an icon) referenced from PIDF in case of the XCAP based > > publishing? Is the content transported separately from the PIDF > > formatted document so that the PIDF includes only a=20 > reference to the > > separately transported content and the compositor is capable for > > linking the information together? This might require that the > > compositor is able to change the content of the reference. >=20 > This is more of a pidf question, I think. The current leaning with=20 > PIDF would be to include such icons by reference. The document stored=20 > in the xcap server would include such a reference. That reference=20 > would presumably be an HTTP URI that can dreference content on the=20 > same server. The user would need to have a directory where they are=20 > permitted to upload content. >=20 I agree that the best way would be to upload the external content = separately using HTTP PUT and insert the URI to PIDF. In some cases the = PA might want to send such information also within the NOTIFY, in which = case the PA would need to fetch the data addressed by the HTTP URI, = insert it as a separate MIME part and replace the HTTP URI in PIDF by a = corresponding cid URI.=20 Can this kind of behaviour be seen purely as an implementation issue, or = is there need to write something about it somewhere?=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 11 21:50:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05173 for ; Tue, 11 Nov 2003 21:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJl56-00077j-Mv for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 21:50:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC2o8Z7027383 for simple-archive@odin.ietf.org; Tue, 11 Nov 2003 21:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJl56-00077a-Gp for simple-web-archive@optimus.ietf.org; Tue, 11 Nov 2003 21:50:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05131; Tue, 11 Nov 2003 21:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJl51-0007D7-00; Tue, 11 Nov 2003 21:50:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJl51-0007D4-00; Tue, 11 Nov 2003 21:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJl50-00076y-2I; Tue, 11 Nov 2003 21:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJl4K-00076f-NA for simple@optimus.ietf.org; Tue, 11 Nov 2003 21:49:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05120 for ; Tue, 11 Nov 2003 21:49:07 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJl4H-0007Cp-00 for simple@ietf.org; Tue, 11 Nov 2003 21:49:17 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJl4G-0007Ch-00 for simple@ietf.org; Tue, 11 Nov 2003 21:49:16 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC2nFB16499 for ; Wed, 12 Nov 2003 04:49:15 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 04:49:15 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 04:49:14 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 04:49:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] comments on draft-isomaki-simple-xcap-publish-usage Message-ID: Thread-Topic: [Simple] comments on draft-isomaki-simple-xcap-publish-usage Thread-Index: AcOnpNkdHEbc7bewRXuH5r5x1ExTEABDqY+g To: , X-OriginalArrivalTime: 12 Nov 2003 02:49:14.0447 (UTC) FILETIME=[8ED025F0:01C3A8C7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 04:49:13 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Thanks for the comments. See below: > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 10 November, 2003 18:06 > To: Simple WG > Subject: [Simple] comments on draft-isomaki-simple-xcap-publish-usage >=20 >=20 > I have a few comments on: >=20 > http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap- > publish-usage-00.txt >=20 > I think this is a good draft, and is the appropriate way to=20 > solve this=20 > problem. >=20 > My main comment is that I think we need to be very clear on the=20 > difference between this mechanism and SIP PUBLISH. I know we went=20 > through a lot of this on the list some time back. In particular, one=20 > could presumably use PUBLISH with an infinitely long Expires header=20 > field, and achieve a near "hard state" publication. I think the real=20 > difference is that this is provisioned data that describes the=20 > presentity independent of any particular device, for which we require=20 > any possible device, and even web pages and provisioning systems, to=20 > manipulate. PUBLISH is really focused on allowing a particular PUA to=20 > publish its view of the presentity, separate from other views=20 > published by other PUAs. As such, manipulating presence hard state=20 > from many different sources using PUBLISH is not easy, as the Etags=20 > would need to be shared. There is no obvious mechanism for=20 > that. Also,=20 > there will be a clear need to do a pure fetch of the hard state=20 > presence data, a feature we don't have with PUBLISH. I think=20 > the draft=20 > should clearly enumerate these problems, and provide guidance on when=20 > to use this mechanism, vs. PUBLISH. >=20 I think this is a good description on the benefits of XCAP presence = publishing application usage compared to SIP PUBLISH. Aki also provided = some consideration why SIP PUBLISH with infinite expiration might not = work. I agree that all this should be added to the next revision of the = draft. > Regarding the open issue: >=20 > > Publishing of external content: how to publish external content > > (e.g., an icon) referenced from PIDF in case of the XCAP based > > publishing? Is the content transported separately from the PIDF > > formatted document so that the PIDF includes only a=20 > reference to the > > separately transported content and the compositor is capable for > > linking the information together? This might require that the > > compositor is able to change the content of the reference. >=20 > This is more of a pidf question, I think. The current leaning with=20 > PIDF would be to include such icons by reference. The document stored=20 > in the xcap server would include such a reference. That reference=20 > would presumably be an HTTP URI that can dreference content on the=20 > same server. The user would need to have a directory where they are=20 > permitted to upload content. >=20 I agree that the best way would be to upload the external content = separately using HTTP PUT and insert the URI to PIDF. In some cases the = PA might want to send such information also within the NOTIFY, in which = case the PA would need to fetch the data addressed by the HTTP URI, = insert it as a separate MIME part and replace the HTTP URI in PIDF by a = corresponding cid URI.=20 Can this kind of behaviour be seen purely as an implementation issue, or = is there need to write something about it somewhere?=20 > -Jonathan R. >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple >=20 Markus _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 00:24:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08698; Wed, 12 Nov 2003 00:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnUW-00013C-00; Wed, 12 Nov 2003 00:24:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJnUW-00012w-00; Wed, 12 Nov 2003 00:24:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnUD-000880-T2; Wed, 12 Nov 2003 00:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnSw-0007Z7-Dp for simple@optimus.ietf.org; Wed, 12 Nov 2003 00:22:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08483 for ; Wed, 12 Nov 2003 00:22:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnSt-0000yZ-00 for simple@ietf.org; Wed, 12 Nov 2003 00:22:51 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJnSs-0000yW-00 for simple@ietf.org; Wed, 12 Nov 2003 00:22:51 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC5Mps05583 for ; Wed, 12 Nov 2003 07:22:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 07:22:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 07:22:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973B8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 Thread-Index: AcOooPLomG1vYa/hQjazVaeP4RUchwAOyRKA To: , , Cc: X-OriginalArrivalTime: 12 Nov 2003 05:22:50.0348 (UTC) FILETIME=[03EB0AC0:01C3A8DD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 07:22:50 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, November 12, 2003 12:12 AM > To: Niemi Aki (NMP/Helsinki); Ben Campbell > Cc: Adam Roach; Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on message-sessions-02 >=20 >=20 > At the risk of beating a dead horse even more: I wasn't trying > to make the point that MSRP should never be used for file > transfer (although the purist in me still believes this to be > "correct"). >=20 > My point was that if you were going to initiate "a specific > session" for file transfer and file transfer only (that is, > no instant messages, just file transfer) as your mail seemed > to be advocating, then you *are* using the wrong protocol. >=20 > More succinctly: there is no valid use case for labeling a > session "file transfer only." First, we agreed that in order not to block a conversation, a long = message should be sent on a separate session. Then there was the concern = that the other endpoint will start using that second session to send = normal short messages. Hence I suggested that an endpoint can restrict = what a session was used for using mime-types (accept-types). Ben pointed to the problem that a message with mime type text/plain = could still carry a very long text file. This is how the = content-disposition discussion started. So, should content disposition = be used in SDP to restrict the type of "things" that can be sent in an = MSRP session? I think it's useful. Regards, Hisham >=20 > /a >=20 > > -----Original Message----- > > From: Aki Niemi [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, November 11, 2003 13:22 > > To: ext Ben Campbell > > Cc: ext Adam Roach; 'hisham.khartabil@nokia.com'; simple@ietf.org > > Subject: Re: [Simple] Comments on message-sessions-02 > >=20 > >=20 > > Hi, > >=20 > > Perhaps I should also clarify my position. Clearly, if you=20 > > are going to=20 > > just do file transfer, there is no sense at all to start to develop=20 > > something else but to use FTP. > >=20 > > But this is not the case here. We are developing MSRP to=20 > > enable sending=20 > > messages in a session, negotiating this in SIP/SDP, and=20 > have tools to=20 > > invoke relays for these sessions. > >=20 > > Now, it is also possible *and* useful to send files, or=20 > things other=20 > > than text/plain, in this session - at which point it becomes "file=20 > > transfer". Please explain why this is bad practice just=20 > because IETF=20 > > already has another protocol to do "file transfer"? > >=20 > > It's not like we are re-developing TCP here. If we were, I'd=20 > > share your=20 > > concerns. As I understand it, in the hour-glass model of Internet,=20 > > multiple application layer protocols that may even overlap in=20 > > functionality is not a bad thing. > >=20 > > Cheers, > > Aki > >=20 > > ext Ben Campbell wrote: > > > From section 5.1: > > >=20 > > > "An analysis of whether it makes sense to do this [file=20 > transfer or=20 > > > sending very large content], rather than sending such=20 > > content over FTP,=20 > > > HTTP, or some other such protocol, is beyond the scope of=20 > > this document." > > >=20 > > > I originally took (and still agree with) Adam's position,=20 > > but that is=20 > > > clearly not the consensus of this group. (If I am=20 > incorrect in that=20 > > > belief, I would love to hear it as I could remove quite a=20 > > bit of text.) > > >=20 > > >=20 > > > Aki Niemi wrote: > > >=20 > > >> > > >> > > >> ext Adam Roach wrote: > > >> > > >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: > > >>> > > >>> > > >>>> These are somewhat orthogonal aspects of a message=20 > > session. It is=20 > > >>>> probably useful to label a specific session as e.g.,=20 > > file-transfer > > >>> > > >>> > > >>> > > >>> > > >>> Yes. You do this by using port 21. If you know a priori that all > > >>> you are going to do is transfer files, the IETF has already > > >>> defined a file transfer protocol. > > >> > > >> > > >> > > >> Right. And if you know a priori that all you are going to=20 > > do is chat=20 > > >> with the other party, then just use IRC. Great, we're done. > > >> > > >> Thanks, > > >> Aki > > >> > > >> > > >>> /a > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 12 00:24:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08813 for ; Wed, 12 Nov 2003 00:24:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnUb-0008Hb-48 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 00:24:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAC5ObLH031838 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 00:24:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnUb-0008HR-0u for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 00:24:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08698; Wed, 12 Nov 2003 00:24:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnUW-00013C-00; Wed, 12 Nov 2003 00:24:32 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJnUW-00012w-00; Wed, 12 Nov 2003 00:24:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnUD-000880-T2; Wed, 12 Nov 2003 00:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJnSw-0007Z7-Dp for simple@optimus.ietf.org; Wed, 12 Nov 2003 00:22:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08483 for ; Wed, 12 Nov 2003 00:22:41 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJnSt-0000yZ-00 for simple@ietf.org; Wed, 12 Nov 2003 00:22:51 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJnSs-0000yW-00 for simple@ietf.org; Wed, 12 Nov 2003 00:22:51 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAC5Mps05583 for ; Wed, 12 Nov 2003 07:22:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 07:22:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 07:22:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on message-sessions-02 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973B8@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 Thread-Index: AcOooPLomG1vYa/hQjazVaeP4RUchwAOyRKA To: , , Cc: X-OriginalArrivalTime: 12 Nov 2003 05:22:50.0348 (UTC) FILETIME=[03EB0AC0:01C3A8DD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 07:22:50 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, November 12, 2003 12:12 AM > To: Niemi Aki (NMP/Helsinki); Ben Campbell > Cc: Adam Roach; Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on message-sessions-02 >=20 >=20 > At the risk of beating a dead horse even more: I wasn't trying > to make the point that MSRP should never be used for file > transfer (although the purist in me still believes this to be > "correct"). >=20 > My point was that if you were going to initiate "a specific > session" for file transfer and file transfer only (that is, > no instant messages, just file transfer) as your mail seemed > to be advocating, then you *are* using the wrong protocol. >=20 > More succinctly: there is no valid use case for labeling a > session "file transfer only." First, we agreed that in order not to block a conversation, a long = message should be sent on a separate session. Then there was the concern = that the other endpoint will start using that second session to send = normal short messages. Hence I suggested that an endpoint can restrict = what a session was used for using mime-types (accept-types). Ben pointed to the problem that a message with mime type text/plain = could still carry a very long text file. This is how the = content-disposition discussion started. So, should content disposition = be used in SDP to restrict the type of "things" that can be sent in an = MSRP session? I think it's useful. Regards, Hisham >=20 > /a >=20 > > -----Original Message----- > > From: Aki Niemi [mailto:aki.niemi@nokia.com] > > Sent: Tuesday, November 11, 2003 13:22 > > To: ext Ben Campbell > > Cc: ext Adam Roach; 'hisham.khartabil@nokia.com'; simple@ietf.org > > Subject: Re: [Simple] Comments on message-sessions-02 > >=20 > >=20 > > Hi, > >=20 > > Perhaps I should also clarify my position. Clearly, if you=20 > > are going to=20 > > just do file transfer, there is no sense at all to start to develop=20 > > something else but to use FTP. > >=20 > > But this is not the case here. We are developing MSRP to=20 > > enable sending=20 > > messages in a session, negotiating this in SIP/SDP, and=20 > have tools to=20 > > invoke relays for these sessions. > >=20 > > Now, it is also possible *and* useful to send files, or=20 > things other=20 > > than text/plain, in this session - at which point it becomes "file=20 > > transfer". Please explain why this is bad practice just=20 > because IETF=20 > > already has another protocol to do "file transfer"? > >=20 > > It's not like we are re-developing TCP here. If we were, I'd=20 > > share your=20 > > concerns. As I understand it, in the hour-glass model of Internet,=20 > > multiple application layer protocols that may even overlap in=20 > > functionality is not a bad thing. > >=20 > > Cheers, > > Aki > >=20 > > ext Ben Campbell wrote: > > > From section 5.1: > > >=20 > > > "An analysis of whether it makes sense to do this [file=20 > transfer or=20 > > > sending very large content], rather than sending such=20 > > content over FTP,=20 > > > HTTP, or some other such protocol, is beyond the scope of=20 > > this document." > > >=20 > > > I originally took (and still agree with) Adam's position,=20 > > but that is=20 > > > clearly not the consensus of this group. (If I am=20 > incorrect in that=20 > > > belief, I would love to hear it as I could remove quite a=20 > > bit of text.) > > >=20 > > >=20 > > > Aki Niemi wrote: > > >=20 > > >> > > >> > > >> ext Adam Roach wrote: > > >> > > >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: > > >>> > > >>> > > >>>> These are somewhat orthogonal aspects of a message=20 > > session. It is=20 > > >>>> probably useful to label a specific session as e.g.,=20 > > file-transfer > > >>> > > >>> > > >>> > > >>> > > >>> Yes. You do this by using port 21. If you know a priori that all > > >>> you are going to do is transfer files, the IETF has already > > >>> defined a file transfer protocol. > > >> > > >> > > >> > > >> Right. And if you know a priori that all you are going to=20 > > do is chat=20 > > >> with the other party, then just use IRC. Great, we're done. > > >> > > >> Thanks, > > >> Aki > > >> > > >> > > >>> /a > > >=20 > > >=20 > > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 09:50:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19521; Wed, 12 Nov 2003 09:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwKo-0007dl-00; Wed, 12 Nov 2003 09:51:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwKo-0007di-00; Wed, 12 Nov 2003 09:51:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwKj-0004zg-L6; Wed, 12 Nov 2003 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwK5-0004x3-K2 for simple@optimus.ietf.org; Wed, 12 Nov 2003 09:50:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19496 for ; Wed, 12 Nov 2003 09:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwK3-0007cx-00 for simple@ietf.org; Wed, 12 Nov 2003 09:50:19 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJwK2-0007ch-00 for simple@ietf.org; Wed, 12 Nov 2003 09:50:18 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hACEnaIc063110; Wed, 12 Nov 2003 08:49:36 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2487D.3080200@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB7017973B8@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973B8@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 08:49:33 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Wednesday, November 12, 2003 12:12 AM >>To: Niemi Aki (NMP/Helsinki); Ben Campbell >>Cc: Adam Roach; Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>Subject: RE: [Simple] Comments on message-sessions-02 >> >> >>At the risk of beating a dead horse even more: I wasn't trying >>to make the point that MSRP should never be used for file >>transfer (although the purist in me still believes this to be >>"correct"). >> >>My point was that if you were going to initiate "a specific >>session" for file transfer and file transfer only (that is, >>no instant messages, just file transfer) as your mail seemed >>to be advocating, then you *are* using the wrong protocol. >> >>More succinctly: there is no valid use case for labeling a >>session "file transfer only." > > > First, we agreed that in order not to block a conversation, a long message should be sent on a separate session. Then there was the concern that the other endpoint will start using that second session to send normal short messages. Hence I suggested that an endpoint can restrict what a session was used for using mime-types (accept-types). > > Ben pointed to the problem that a message with mime type text/plain could still carry a very long text file. This is how the content-disposition discussion started. So, should content disposition be used in SDP to restrict the type of "things" that can be sent in an MSRP session? I think it's useful. I think it could be useful, but it doesn't feel like the best semantic. Content-disposition really gives hints on what the receiver endpoint should do with a piece of content. It doesn't say anything about what an endpoint should send. Also, if we used the standard MIME syntax, it can be pretty complex to put into an sdp document. If we were to decide to label in the first place, I suspect we would have to invent something for it. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 12 09:51:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19551 for ; Wed, 12 Nov 2003 09:51:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwKr-00050S-Dh for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 09:51:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACEp962019241 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 09:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwKr-00050G-9V for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 09:51:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19521; Wed, 12 Nov 2003 09:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwKo-0007dl-00; Wed, 12 Nov 2003 09:51:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwKo-0007di-00; Wed, 12 Nov 2003 09:51:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwKj-0004zg-L6; Wed, 12 Nov 2003 09:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwK5-0004x3-K2 for simple@optimus.ietf.org; Wed, 12 Nov 2003 09:50:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19496 for ; Wed, 12 Nov 2003 09:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwK3-0007cx-00 for simple@ietf.org; Wed, 12 Nov 2003 09:50:19 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AJwK2-0007ch-00 for simple@ietf.org; Wed, 12 Nov 2003 09:50:18 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hACEnaIc063110; Wed, 12 Nov 2003 08:49:36 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2487D.3080200@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: adam@dynamicsoft.com, aki.niemi@nokia.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 References: <2038BCC78B1AD641891A0D1AE133DBB7017973B8@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973B8@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 08:49:33 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Adam Roach [mailto:adam@dynamicsoft.com] >>Sent: Wednesday, November 12, 2003 12:12 AM >>To: Niemi Aki (NMP/Helsinki); Ben Campbell >>Cc: Adam Roach; Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>Subject: RE: [Simple] Comments on message-sessions-02 >> >> >>At the risk of beating a dead horse even more: I wasn't trying >>to make the point that MSRP should never be used for file >>transfer (although the purist in me still believes this to be >>"correct"). >> >>My point was that if you were going to initiate "a specific >>session" for file transfer and file transfer only (that is, >>no instant messages, just file transfer) as your mail seemed >>to be advocating, then you *are* using the wrong protocol. >> >>More succinctly: there is no valid use case for labeling a >>session "file transfer only." > > > First, we agreed that in order not to block a conversation, a long message should be sent on a separate session. Then there was the concern that the other endpoint will start using that second session to send normal short messages. Hence I suggested that an endpoint can restrict what a session was used for using mime-types (accept-types). > > Ben pointed to the problem that a message with mime type text/plain could still carry a very long text file. This is how the content-disposition discussion started. So, should content disposition be used in SDP to restrict the type of "things" that can be sent in an MSRP session? I think it's useful. I think it could be useful, but it doesn't feel like the best semantic. Content-disposition really gives hints on what the receiver endpoint should do with a piece of content. It doesn't say anything about what an endpoint should send. Also, if we used the standard MIME syntax, it can be pretty complex to put into an sdp document. If we were to decide to label in the first place, I suspect we would have to invent something for it. [...] _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 09:56:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19756; Wed, 12 Nov 2003 09:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwQa-0007ii-00; Wed, 12 Nov 2003 09:57:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwQa-0007if-00; Wed, 12 Nov 2003 09:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwQY-0005nv-9P; Wed, 12 Nov 2003 09:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwQD-0005nR-MS for simple@optimus.ietf.org; Wed, 12 Nov 2003 09:56:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19748 for ; Wed, 12 Nov 2003 09:56:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwQB-0007iK-00 for simple@ietf.org; Wed, 12 Nov 2003 09:56:39 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AJwQB-0007iH-00 for simple@ietf.org; Wed, 12 Nov 2003 09:56:39 -0500 Received: from softarmor.com (dyn132-174.ietf58.ietf.org [130.129.132.174]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hACEvQv4009579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2003 08:57:30 -0600 Message-ID: <3FB249FB.6080806@softarmor.com> From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <3FAC1882.7070605@dynamicsoft.com> In-Reply-To: <3FAC1882.7070605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 08:55:55 -0600 Content-Transfer-Encoding: 7bit > I dont get this. I thought that an ad-hoc list would be scoped to the > subscription, in which case, there wouldnt be any other subscribers. Am > I missing something? Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc conference. Would "members" of the list (i.e., participants in the conference) subscribe to the list, or to the conference in order to learn about changes to the participant set? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 12 09:57:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19816 for ; Wed, 12 Nov 2003 09:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwQe-0005s8-3J for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 09:57:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACEv8gZ022566 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 09:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwQd-0005rt-Pd for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 09:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19756; Wed, 12 Nov 2003 09:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwQa-0007ii-00; Wed, 12 Nov 2003 09:57:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJwQa-0007if-00; Wed, 12 Nov 2003 09:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwQY-0005nv-9P; Wed, 12 Nov 2003 09:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJwQD-0005nR-MS for simple@optimus.ietf.org; Wed, 12 Nov 2003 09:56:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19748 for ; Wed, 12 Nov 2003 09:56:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJwQB-0007iK-00 for simple@ietf.org; Wed, 12 Nov 2003 09:56:39 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AJwQB-0007iH-00 for simple@ietf.org; Wed, 12 Nov 2003 09:56:39 -0500 Received: from softarmor.com (dyn132-174.ietf58.ietf.org [130.129.132.174]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hACEvQv4009579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Nov 2003 08:57:30 -0600 Message-ID: <3FB249FB.6080806@softarmor.com> From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] ad-hoc list subscriptions References: <3FAC1882.7070605@dynamicsoft.com> In-Reply-To: <3FAC1882.7070605@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 08:55:55 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I dont get this. I thought that an ad-hoc list would be scoped to the > subscription, in which case, there wouldnt be any other subscribers. Am > I missing something? Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc conference. Would "members" of the list (i.e., participants in the conference) subscribe to the list, or to the conference in order to learn about changes to the participant set? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 12:23:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28518; Wed, 12 Nov 2003 12:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyir-0002iL-00; Wed, 12 Nov 2003 12:24:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJyir-0002iI-00; Wed, 12 Nov 2003 12:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyim-0001yc-MN; Wed, 12 Nov 2003 12:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyiA-0001xx-Ba for simple@optimus.ietf.org; Wed, 12 Nov 2003 12:23:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28495 for ; Wed, 12 Nov 2003 12:23:08 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyi8-0002hp-00 for simple@ietf.org; Wed, 12 Nov 2003 12:23:20 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJyi7-0002hi-00 for simple@ietf.org; Wed, 12 Nov 2003 12:23:19 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACHNIA17480 for ; Wed, 12 Nov 2003 19:23:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 19:23:17 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 19:23:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOnwaONJmDaf/WIT8yoi09VEgz2aQBfY7lQ To: , , X-OriginalArrivalTime: 12 Nov 2003 17:23:17.0935 (UTC) FILETIME=[A9915BF0:01C3A941] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 19:23:17 +0200 Content-Transfer-Encoding: quoted-printable Hi, I support Adam's proposal below compared to using a CID URI directly as = the Request-URI, even though it might be possible to get the routing = work with pre-loaded Routes. I believe this would be the way also to = solve requirement 5 in = http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00.= txt. In any case it would be better to solve the = sending-to-an-ad-hoc-list issue more generally than just for SUBSCRIBE. Also the support for XCAP resource list is very useful in some = scenarios. In a recent discussion I proposed that we could define = extensions like to XCAP resource list, and this would mean = that you could send a MESSAGE to that list too. I still believe this to = be useful, but I see Adam's proposal complementary to this. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Adam Roach > Sent: 10 November, 2003 21:33 > To: Jonathan Rosenberg; Simple WG > Subject: RE: [Simple] ad-hoc list subscriptions >=20 >=20 > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: >=20 > > (3) its a CID URI, referring to the list in the body of the request >=20 > That has the potential to make routing very difficult. If the=20 > first proxy > that you hit doesn't know what the cid scheme means, then=20 > things won't work. > It seems to me that the most flexible approach would be=20 > something like: >=20 > SUBSCRIBE=20 > sip:group@example.com;list=3Dcid:cn35t8jf02@terminal.foo.com SIP/2.0 >=20 > Nice thing about this is that you could also do something like: >=20 > SUBSCRIBE > sip:group@example.com;list=3Dhttp://xcap.example.com/services/pr > esence-lists/u > sers/bill/fr.xml SIP/2.0 >=20 > /a >=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 exim@www1.ietf.org Wed Nov 12 12:24:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28564 for ; Wed, 12 Nov 2003 12:24:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyiu-00020o-5k for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 12:24:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACHO8CX007728 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 12:24:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyiu-00020Z-20 for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 12:24:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28518; Wed, 12 Nov 2003 12:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyir-0002iL-00; Wed, 12 Nov 2003 12:24:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJyir-0002iI-00; Wed, 12 Nov 2003 12:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyim-0001yc-MN; Wed, 12 Nov 2003 12:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyiA-0001xx-Ba for simple@optimus.ietf.org; Wed, 12 Nov 2003 12:23:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28495 for ; Wed, 12 Nov 2003 12:23:08 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyi8-0002hp-00 for simple@ietf.org; Wed, 12 Nov 2003 12:23:20 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJyi7-0002hi-00 for simple@ietf.org; Wed, 12 Nov 2003 12:23:19 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACHNIA17480 for ; Wed, 12 Nov 2003 19:23:18 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 19:23:17 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 19:23:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOnwaONJmDaf/WIT8yoi09VEgz2aQBfY7lQ To: , , X-OriginalArrivalTime: 12 Nov 2003 17:23:17.0935 (UTC) FILETIME=[A9915BF0:01C3A941] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 19:23:17 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I support Adam's proposal below compared to using a CID URI directly as = the Request-URI, even though it might be possible to get the routing = work with pre-loaded Routes. I believe this would be the way also to = solve requirement 5 in = http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00.= txt. In any case it would be better to solve the = sending-to-an-ad-hoc-list issue more generally than just for SUBSCRIBE. Also the support for XCAP resource list is very useful in some = scenarios. In a recent discussion I proposed that we could define = extensions like to XCAP resource list, and this would mean = that you could send a MESSAGE to that list too. I still believe this to = be useful, but I see Adam's proposal complementary to this. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Adam Roach > Sent: 10 November, 2003 21:33 > To: Jonathan Rosenberg; Simple WG > Subject: RE: [Simple] ad-hoc list subscriptions >=20 >=20 > Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] writes: >=20 > > (3) its a CID URI, referring to the list in the body of the request >=20 > That has the potential to make routing very difficult. If the=20 > first proxy > that you hit doesn't know what the cid scheme means, then=20 > things won't work. > It seems to me that the most flexible approach would be=20 > something like: >=20 > SUBSCRIBE=20 > sip:group@example.com;list=3Dcid:cn35t8jf02@terminal.foo.com SIP/2.0 >=20 > Nice thing about this is that you could also do something like: >=20 > SUBSCRIBE > sip:group@example.com;list=3Dhttp://xcap.example.com/services/pr > esence-lists/u > sers/bill/fr.xml SIP/2.0 >=20 > /a >=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-admin@ietf.org Wed Nov 12 12:33:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29021; Wed, 12 Nov 2003 12:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJysY-0002tI-00; Wed, 12 Nov 2003 12:34:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJysY-0002tF-00; Wed, 12 Nov 2003 12:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJysT-0002lg-7I; Wed, 12 Nov 2003 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyrc-0002k2-TU for simple@optimus.ietf.org; Wed, 12 Nov 2003 12:33:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28932 for ; Wed, 12 Nov 2003 12:32:55 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyrb-0002rZ-00 for simple@ietf.org; Wed, 12 Nov 2003 12:33:07 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJyra-0002rW-00 for simple@ietf.org; Wed, 12 Nov 2003 12:33:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACHX4A28487 for ; Wed, 12 Nov 2003 19:33:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 19:33:04 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 19:33:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOpLUKqFLTHP0vaTUyt98EX2IFvhQAFIGPA To: , Cc: X-OriginalArrivalTime: 12 Nov 2003 17:33:04.0874 (UTC) FILETIME=[076924A0:01C3A943] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 19:33:04 +0200 Content-Transfer-Encoding: quoted-printable Hi, I believe the best way would be for them to subscribe to = conference-state event package, if that is available. But I guess there = is a bigger issue here: What is the relationship between a conference = started through an exploder and a conference setup for with CPCP a la = XCON. Is it possible to migrate from an exploder conference to = CPCP-controllable one (given that the server supports CPCP, conference = notification service etc.)? I have yet another requirement for this ad hoc list / exploder solution. = Especially in the case of MESSAGE to a list, it would be nice to be able = to convey to the recipients the list of other recipients. It should be = possible for the original sender to indicate this. It shouldn't be too = hard to map the headers/payload from incoming to outgoing side for this = purpose within the "exploder server". Markus=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Dean Willis > Sent: 12 November, 2003 16:56 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] ad-hoc list subscriptions >=20 >=20 >=20 > > I dont get this. I thought that an ad-hoc list would be=20 > scoped to the=20 > > subscription, in which case, there wouldnt be any other=20 > subscribers. Am=20 > > I missing something? >=20 > Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc=20 > conference. Would "members" of the list (i.e., participants in the=20 > conference) subscribe to the list, or to the conference in order to=20 > learn about changes to the participant set? >=20 > -- > Dean >=20 >=20 >=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 exim@www1.ietf.org Wed Nov 12 12:34:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29062 for ; Wed, 12 Nov 2003 12:34:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyse-0002nP-UI for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 12:34:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACHYCVS010747 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 12:34:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyse-0002nG-RW for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 12:34:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29021; Wed, 12 Nov 2003 12:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJysY-0002tI-00; Wed, 12 Nov 2003 12:34:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJysY-0002tF-00; Wed, 12 Nov 2003 12:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJysT-0002lg-7I; Wed, 12 Nov 2003 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJyrc-0002k2-TU for simple@optimus.ietf.org; Wed, 12 Nov 2003 12:33:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28932 for ; Wed, 12 Nov 2003 12:32:55 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJyrb-0002rZ-00 for simple@ietf.org; Wed, 12 Nov 2003 12:33:07 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJyra-0002rW-00 for simple@ietf.org; Wed, 12 Nov 2003 12:33:06 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hACHX4A28487 for ; Wed, 12 Nov 2003 19:33:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 12 Nov 2003 19:33:04 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Nov 2003 19:33:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOpLUKqFLTHP0vaTUyt98EX2IFvhQAFIGPA To: , Cc: X-OriginalArrivalTime: 12 Nov 2003 17:33:04.0874 (UTC) FILETIME=[076924A0:01C3A943] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 19:33:04 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I believe the best way would be for them to subscribe to = conference-state event package, if that is available. But I guess there = is a bigger issue here: What is the relationship between a conference = started through an exploder and a conference setup for with CPCP a la = XCON. Is it possible to migrate from an exploder conference to = CPCP-controllable one (given that the server supports CPCP, conference = notification service etc.)? I have yet another requirement for this ad hoc list / exploder solution. = Especially in the case of MESSAGE to a list, it would be nice to be able = to convey to the recipients the list of other recipients. It should be = possible for the original sender to indicate this. It shouldn't be too = hard to map the headers/payload from incoming to outgoing side for this = purpose within the "exploder server". Markus=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Dean Willis > Sent: 12 November, 2003 16:56 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] ad-hoc list subscriptions >=20 >=20 >=20 > > I dont get this. I thought that an ad-hoc list would be=20 > scoped to the=20 > > subscription, in which case, there wouldnt be any other=20 > subscribers. Am=20 > > I missing something? >=20 > Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc=20 > conference. Would "members" of the list (i.e., participants in the=20 > conference) subscribe to the list, or to the conference in order to=20 > learn about changes to the participant set? >=20 > -- > Dean >=20 >=20 >=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-admin@ietf.org Wed Nov 12 13:40:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01423; Wed, 12 Nov 2003 13:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzuV-0003jX-00; Wed, 12 Nov 2003 13:40:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJzuV-0003jU-00; Wed, 12 Nov 2003 13:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzuL-00070O-D4; Wed, 12 Nov 2003 13:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJztb-0006zi-WB for simple@optimus.ietf.org; Wed, 12 Nov 2003 13:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01392 for ; Wed, 12 Nov 2003 13:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJztZ-0003ii-00 for simple@ietf.org; Wed, 12 Nov 2003 13:39:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJztZ-0003ib-00 for simple@ietf.org; Wed, 12 Nov 2003 13:39:13 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 10:45:29 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACIcaw5000871; Wed, 12 Nov 2003 10:38:36 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-38.cisco.com [10.86.240.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX96519; Wed, 12 Nov 2003 13:38:34 -0500 (EST) Message-ID: <3FB27E2A.9000506@cisco.com> 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: Markus.Isomaki@nokia.com CC: dean.willis@softarmor.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 13:38:34 -0500 Content-Transfer-Encoding: 7bit There seems to be an assumption here that sending an INVITE to an ad hoc list should create a conference. That is certainly one interpretation, but not the only possible one. If the ad hoc list server is a simple message exploder then you probably aren't going to get a conference. If you have a list of people and want to set up a conference there are other ways to do it, so trying to bend ad hoc list to do this may not be justified. Paul Markus.Isomaki@nokia.com wrote: > Hi, > > I believe the best way would be for them to subscribe to conference-state event package, if that is available. But I guess there is a bigger issue here: What is the relationship between a conference started through an exploder and a conference setup for with CPCP a la XCON. Is it possible to migrate from an exploder conference to CPCP-controllable one (given that the server supports CPCP, conference notification service etc.)? > > I have yet another requirement for this ad hoc list / exploder solution. Especially in the case of MESSAGE to a list, it would be nice to be able to convey to the recipients the list of other recipients. It should be possible for the original sender to indicate this. It shouldn't be too hard to map the headers/payload from incoming to outgoing side for this purpose within the "exploder server". > > Markus > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Dean Willis >>Sent: 12 November, 2003 16:56 >>To: Jonathan Rosenberg >>Cc: Simple WG >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >> >> >>>I dont get this. I thought that an ad-hoc list would be >> >>scoped to the >> >>>subscription, in which case, there wouldnt be any other >> >>subscribers. Am >> >>>I missing something? >> >>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>conference. Would "members" of the list (i.e., participants in the >>conference) subscribe to the list, or to the conference in order to >>learn about changes to the participant set? >> >>-- >>Dean >> >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Wed Nov 12 13:40:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01448 for ; Wed, 12 Nov 2003 13:40:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzuZ-00071e-1Z for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 13:40:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACIeFIS027003 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 13:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzuY-00071S-PD for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 13:40:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01423; Wed, 12 Nov 2003 13:40:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJzuV-0003jX-00; Wed, 12 Nov 2003 13:40:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AJzuV-0003jU-00; Wed, 12 Nov 2003 13:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJzuL-00070O-D4; Wed, 12 Nov 2003 13:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJztb-0006zi-WB for simple@optimus.ietf.org; Wed, 12 Nov 2003 13:39:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01392 for ; Wed, 12 Nov 2003 13:39:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJztZ-0003ii-00 for simple@ietf.org; Wed, 12 Nov 2003 13:39:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJztZ-0003ib-00 for simple@ietf.org; Wed, 12 Nov 2003 13:39:13 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Nov 2003 10:45:29 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hACIcaw5000871; Wed, 12 Nov 2003 10:38:36 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-38.cisco.com [10.86.240.38]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADX96519; Wed, 12 Nov 2003 13:38:34 -0500 (EST) Message-ID: <3FB27E2A.9000506@cisco.com> 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: Markus.Isomaki@nokia.com CC: dean.willis@softarmor.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 13:38:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There seems to be an assumption here that sending an INVITE to an ad hoc list should create a conference. That is certainly one interpretation, but not the only possible one. If the ad hoc list server is a simple message exploder then you probably aren't going to get a conference. If you have a list of people and want to set up a conference there are other ways to do it, so trying to bend ad hoc list to do this may not be justified. Paul Markus.Isomaki@nokia.com wrote: > Hi, > > I believe the best way would be for them to subscribe to conference-state event package, if that is available. But I guess there is a bigger issue here: What is the relationship between a conference started through an exploder and a conference setup for with CPCP a la XCON. Is it possible to migrate from an exploder conference to CPCP-controllable one (given that the server supports CPCP, conference notification service etc.)? > > I have yet another requirement for this ad hoc list / exploder solution. Especially in the case of MESSAGE to a list, it would be nice to be able to convey to the recipients the list of other recipients. It should be possible for the original sender to indicate this. It shouldn't be too hard to map the headers/payload from incoming to outgoing side for this purpose within the "exploder server". > > Markus > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Dean Willis >>Sent: 12 November, 2003 16:56 >>To: Jonathan Rosenberg >>Cc: Simple WG >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >> >> >>>I dont get this. I thought that an ad-hoc list would be >> >>scoped to the >> >>>subscription, in which case, there wouldnt be any other >> >>subscribers. Am >> >>>I missing something? >> >>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>conference. Would "members" of the list (i.e., participants in the >>conference) subscribe to the list, or to the conference in order to >>learn about changes to the participant set? >> >>-- >>Dean >> >> >> >>_______________________________________________ >>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-admin@ietf.org Wed Nov 12 14:36:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03489; Wed, 12 Nov 2003 14:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0nZ-0004Pp-00; Wed, 12 Nov 2003 14:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK0nZ-0004Pm-00; Wed, 12 Nov 2003 14:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0nU-0001O1-EP; Wed, 12 Nov 2003 14:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0ms-0001LL-Nh for simple@optimus.ietf.org; Wed, 12 Nov 2003 14:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03465 for ; Wed, 12 Nov 2003 14:36:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0mp-0004PS-00 for simple@ietf.org; Wed, 12 Nov 2003 14:36:19 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK0mo-0004PJ-00 for simple@ietf.org; Wed, 12 Nov 2003 14:36:18 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hACJYUGd021637; Wed, 12 Nov 2003 13:34:31 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 13:34:31 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com Cc: dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 13:34:30 -0600 I would argue that, as with every other request you send, the application behavior depends on the request URI. So, for example, I could deploy an application server in the middle of the network that treats: INVITE sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 ...very differently than... INVITE sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 /a > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 12, 2003 12:39 > To: Markus.Isomaki@nokia.com > Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; > simple@ietf.org > Subject: Re: [Simple] ad-hoc list subscriptions > > > There seems to be an assumption here that sending an INVITE > to an ad hoc > list should create a conference. That is certainly one > interpretation, > but not the only possible one. If the ad hoc list server is a simple > message exploder then you probably aren't going to get a conference. > > If you have a list of people and want to set up a conference > there are > other ways to do it, so trying to bend ad hoc list to do this > may not be > justified. > > Paul > > Markus.Isomaki@nokia.com wrote: > > Hi, > > > > I believe the best way would be for them to subscribe to > conference-state event package, if that is available. But I > guess there is a bigger issue here: What is the relationship > between a conference started through an exploder and a > conference setup for with CPCP a la XCON. Is it possible to > migrate from an exploder conference to CPCP-controllable one > (given that the server supports CPCP, conference notification > service etc.)? > > > > I have yet another requirement for this ad hoc list / > exploder solution. Especially in the case of MESSAGE to a > list, it would be nice to be able to convey to the recipients > the list of other recipients. It should be possible for the > original sender to indicate this. It shouldn't be too hard to > map the headers/payload from incoming to outgoing side for > this purpose within the "exploder server". > > > > Markus > > > > > >>-----Original Message----- > >>From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Dean Willis > >>Sent: 12 November, 2003 16:56 > >>To: Jonathan Rosenberg > >>Cc: Simple WG > >>Subject: Re: [Simple] ad-hoc list subscriptions > >> > >> > >> > >> > >>>I dont get this. I thought that an ad-hoc list would be > >> > >>scoped to the > >> > >>>subscription, in which case, there wouldnt be any other > >> > >>subscribers. Am > >> > >>>I missing something? > >> > >>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc > >>conference. Would "members" of the list (i.e., participants in the > >>conference) subscribe to the list, or to the conference in order to > >>learn about changes to the participant set? > >> > >>-- > >>Dean > >> > >> > >> > >>_______________________________________________ > >>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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 12 14:37:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03526 for ; Wed, 12 Nov 2003 14:37:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0nd-0001RH-UC for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 14:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACJb9Er005525 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 14:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0nd-0001Qu-JV for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 14:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03489; Wed, 12 Nov 2003 14:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0nZ-0004Pp-00; Wed, 12 Nov 2003 14:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK0nZ-0004Pm-00; Wed, 12 Nov 2003 14:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0nU-0001O1-EP; Wed, 12 Nov 2003 14:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK0ms-0001LL-Nh for simple@optimus.ietf.org; Wed, 12 Nov 2003 14:36:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03465 for ; Wed, 12 Nov 2003 14:36:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK0mp-0004PS-00 for simple@ietf.org; Wed, 12 Nov 2003 14:36:19 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK0mo-0004PJ-00 for simple@ietf.org; Wed, 12 Nov 2003 14:36:18 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hACJYUGd021637; Wed, 12 Nov 2003 13:34:31 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 13:34:31 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com Cc: dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 13:34:30 -0600 I would argue that, as with every other request you send, the application behavior depends on the request URI. So, for example, I could deploy an application server in the middle of the network that treats: INVITE sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 ...very differently than... INVITE sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 /a > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 12, 2003 12:39 > To: Markus.Isomaki@nokia.com > Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; > simple@ietf.org > Subject: Re: [Simple] ad-hoc list subscriptions > > > There seems to be an assumption here that sending an INVITE > to an ad hoc > list should create a conference. That is certainly one > interpretation, > but not the only possible one. If the ad hoc list server is a simple > message exploder then you probably aren't going to get a conference. > > If you have a list of people and want to set up a conference > there are > other ways to do it, so trying to bend ad hoc list to do this > may not be > justified. > > Paul > > Markus.Isomaki@nokia.com wrote: > > Hi, > > > > I believe the best way would be for them to subscribe to > conference-state event package, if that is available. But I > guess there is a bigger issue here: What is the relationship > between a conference started through an exploder and a > conference setup for with CPCP a la XCON. Is it possible to > migrate from an exploder conference to CPCP-controllable one > (given that the server supports CPCP, conference notification > service etc.)? > > > > I have yet another requirement for this ad hoc list / > exploder solution. Especially in the case of MESSAGE to a > list, it would be nice to be able to convey to the recipients > the list of other recipients. It should be possible for the > original sender to indicate this. It shouldn't be too hard to > map the headers/payload from incoming to outgoing side for > this purpose within the "exploder server". > > > > Markus > > > > > >>-----Original Message----- > >>From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Dean Willis > >>Sent: 12 November, 2003 16:56 > >>To: Jonathan Rosenberg > >>Cc: Simple WG > >>Subject: Re: [Simple] ad-hoc list subscriptions > >> > >> > >> > >> > >>>I dont get this. I thought that an ad-hoc list would be > >> > >>scoped to the > >> > >>>subscription, in which case, there wouldnt be any other > >> > >>subscribers. Am > >> > >>>I missing something? > >> > >>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc > >>conference. Would "members" of the list (i.e., participants in the > >>conference) subscribe to the list, or to the conference in order to > >>learn about changes to the participant set? > >> > >>-- > >>Dean > >> > >> > >> > >>_______________________________________________ > >>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 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 16:47:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11654; Wed, 12 Nov 2003 16:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2pS-00073Y-00; Wed, 12 Nov 2003 16:47:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK2pS-00073T-00; Wed, 12 Nov 2003 16:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2pI-0001Xf-QJ; Wed, 12 Nov 2003 16:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2oa-0001RG-OY for simple@optimus.ietf.org; Wed, 12 Nov 2003 16:46:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11601 for ; Wed, 12 Nov 2003 16:46:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2oY-00072a-00 for simple@ietf.org; Wed, 12 Nov 2003 16:46:14 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AK2oX-00071w-00 for simple@ietf.org; Wed, 12 Nov 2003 16:46:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hACLjhd23476 for ; Wed, 12 Nov 2003 15:45:43 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1068673535.1113.145.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] agenda adjustment Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 15:45:36 -0600 Content-Transfer-Encoding: 7bit I've received a request from Jonathan for an agenda change to allow the key participants in the GEOPRIV/XCAP discussions to be present for the xcap-auth section of the SIMPLE meeting. Lisa Dusseault has also asked for two minutes to discuss some ideas she has on unifying they ways we are moving partial information (document deltas) in xcap, webdav, and some other places. The changes are reflected below. RjS > SIMPLE Agenda > IETF 58 > > Thursday 11/13/03 - Morning Sesson > 0900-1130 Salon A > > 0h 10m : Agenda bashing, status (chairs) > 1h 00m : msrp (Ben) > draft-ietf-simple-message-sessions-02.txt > 0h 30m : pdoc-usage (Robert) > draft-sparks-simple-pdoc-usage-00.txt 0h 15m : partial-notification (Mikko) draft-ietf-simple-partial-notify-00.txt 0h 15m : prescaps (Mikko) draft-lonnfors-simple-prescaps-ext-02.txt 0h 15m : presence/im-wireless-reqs (Aki/Krisztian) draft-niemi-simple-im-wireless-reqs-02.txt draft-kiss-simple-presence-wireless-reqs-03.txt 0h 2m : Discussion: Shared issues with document deltas between xcap, webdav, and others (Lisa Dusseault) > > > Thursday 11/13/03 - Afternoon I > 1300-1500 Salon A 0h 45m : xcap (Jonathan) draft-ietf-simple-xcap-01.txt draft-ietf-simple-xcap-auth-usage-01.txt draft-ietf-simple-xcap-list-usage-01.txt > 0h 15m : filtering (Hisham) > draft-khartabil-simple-filter-format-01.txt > 0h 15m : winfo-history (Aki) > draft-niemi-simple-winfo-history-00.txt > 0h 15m : adhoc-event-list (Orit) > draft-levin-simple-adhoc-list-00.txt > 0h 15m : xcap-publish-usage (Markus) > draft-isomaki-simple-xcap-publish-usage-00.txt > 0h 15m : summary, review of assigned actions (chairs) > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 12 16:47:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11689 for ; Wed, 12 Nov 2003 16:47:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2pW-0001aO-Sn for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 16:47:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLlE1J006092 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 16:47:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2pW-0001a8-NC for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 16:47:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11654; Wed, 12 Nov 2003 16:47:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2pS-00073Y-00; Wed, 12 Nov 2003 16:47:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK2pS-00073T-00; Wed, 12 Nov 2003 16:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2pI-0001Xf-QJ; Wed, 12 Nov 2003 16:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2oa-0001RG-OY for simple@optimus.ietf.org; Wed, 12 Nov 2003 16:46:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11601 for ; Wed, 12 Nov 2003 16:46:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2oY-00072a-00 for simple@ietf.org; Wed, 12 Nov 2003 16:46:14 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AK2oX-00071w-00 for simple@ietf.org; Wed, 12 Nov 2003 16:46:14 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hACLjhd23476 for ; Wed, 12 Nov 2003 15:45:43 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1068673535.1113.145.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] agenda adjustment Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 15:45:36 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've received a request from Jonathan for an agenda change to allow the key participants in the GEOPRIV/XCAP discussions to be present for the xcap-auth section of the SIMPLE meeting. Lisa Dusseault has also asked for two minutes to discuss some ideas she has on unifying they ways we are moving partial information (document deltas) in xcap, webdav, and some other places. The changes are reflected below. RjS > SIMPLE Agenda > IETF 58 > > Thursday 11/13/03 - Morning Sesson > 0900-1130 Salon A > > 0h 10m : Agenda bashing, status (chairs) > 1h 00m : msrp (Ben) > draft-ietf-simple-message-sessions-02.txt > 0h 30m : pdoc-usage (Robert) > draft-sparks-simple-pdoc-usage-00.txt 0h 15m : partial-notification (Mikko) draft-ietf-simple-partial-notify-00.txt 0h 15m : prescaps (Mikko) draft-lonnfors-simple-prescaps-ext-02.txt 0h 15m : presence/im-wireless-reqs (Aki/Krisztian) draft-niemi-simple-im-wireless-reqs-02.txt draft-kiss-simple-presence-wireless-reqs-03.txt 0h 2m : Discussion: Shared issues with document deltas between xcap, webdav, and others (Lisa Dusseault) > > > Thursday 11/13/03 - Afternoon I > 1300-1500 Salon A 0h 45m : xcap (Jonathan) draft-ietf-simple-xcap-01.txt draft-ietf-simple-xcap-auth-usage-01.txt draft-ietf-simple-xcap-list-usage-01.txt > 0h 15m : filtering (Hisham) > draft-khartabil-simple-filter-format-01.txt > 0h 15m : winfo-history (Aki) > draft-niemi-simple-winfo-history-00.txt > 0h 15m : adhoc-event-list (Orit) > draft-levin-simple-adhoc-list-00.txt > 0h 15m : xcap-publish-usage (Markus) > draft-isomaki-simple-xcap-publish-usage-00.txt > 0h 15m : summary, review of assigned actions (chairs) > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 17:21:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13042; Wed, 12 Nov 2003 17:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3NG-0007eV-00; Wed, 12 Nov 2003 17:22:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK3NF-0007eS-00; Wed, 12 Nov 2003 17:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3NB-0003s4-5m; Wed, 12 Nov 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3N3-0003qy-7q for simple@optimus.ietf.org; Wed, 12 Nov 2003 17:21:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13023 for ; Wed, 12 Nov 2003 17:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3N0-0007dp-00 for simple@ietf.org; Wed, 12 Nov 2003 17:21:50 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AK3Mz-0007dS-00 for simple@ietf.org; Wed, 12 Nov 2003 17:21:50 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hACMJkIc001331; Wed, 12 Nov 2003 16:19:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2B1FF.6020703@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 16:19:43 -0600 Content-Transfer-Encoding: 7bit I concur with Adam. The basic URI (not counting the list parameter) identifies an application that knows to do something with the list parameter. Some other application might just ignore the list parameter. Adam Roach wrote: > I would argue that, as with every other request you send, > the application behavior depends on the request URI. > > So, for example, I could deploy an application server in > the middle of the network that treats: > > INVITE sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com > SIP/2.0 > > ...very differently than... > > INVITE sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > /a > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, November 12, 2003 12:39 >>To: Markus.Isomaki@nokia.com >>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >>There seems to be an assumption here that sending an INVITE >>to an ad hoc >>list should create a conference. That is certainly one >>interpretation, >>but not the only possible one. If the ad hoc list server is a simple >>message exploder then you probably aren't going to get a conference. >> >>If you have a list of people and want to set up a conference >>there are >>other ways to do it, so trying to bend ad hoc list to do this >>may not be >>justified. >> >> Paul >> >>Markus.Isomaki@nokia.com wrote: >> >>>Hi, >>> >>>I believe the best way would be for them to subscribe to >> >>conference-state event package, if that is available. But I >>guess there is a bigger issue here: What is the relationship >>between a conference started through an exploder and a >>conference setup for with CPCP a la XCON. Is it possible to >>migrate from an exploder conference to CPCP-controllable one >>(given that the server supports CPCP, conference notification >>service etc.)? >> >>>I have yet another requirement for this ad hoc list / >> >>exploder solution. Especially in the case of MESSAGE to a >>list, it would be nice to be able to convey to the recipients >>the list of other recipients. It should be possible for the >>original sender to indicate this. It shouldn't be too hard to >>map the headers/payload from incoming to outgoing side for >>this purpose within the "exploder server". >> >>>Markus >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Dean Willis >>>>Sent: 12 November, 2003 16:56 >>>>To: Jonathan Rosenberg >>>>Cc: Simple WG >>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>> >>>> >>>> >>>> >>>> >>>>>I dont get this. I thought that an ad-hoc list would be >>>> >>>>scoped to the >>>> >>>> >>>>>subscription, in which case, there wouldnt be any other >>>> >>>>subscribers. Am >>>> >>>> >>>>>I missing something? >>>> >>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>>>conference. Would "members" of the list (i.e., participants in the >>>>conference) subscribe to the list, or to the conference in order to >>>>learn about changes to the participant set? >>>> >>>>-- >>>>Dean >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 >> > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Nov 12 17:22:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13069 for ; Wed, 12 Nov 2003 17:22:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3NK-0003tI-2e for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 17:22:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACMMA69014955 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 17:22:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3NJ-0003t8-Vd for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 17:22:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13042; Wed, 12 Nov 2003 17:21:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3NG-0007eV-00; Wed, 12 Nov 2003 17:22:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK3NF-0007eS-00; Wed, 12 Nov 2003 17:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3NB-0003s4-5m; Wed, 12 Nov 2003 17:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3N3-0003qy-7q for simple@optimus.ietf.org; Wed, 12 Nov 2003 17:21:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13023 for ; Wed, 12 Nov 2003 17:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3N0-0007dp-00 for simple@ietf.org; Wed, 12 Nov 2003 17:21:50 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AK3Mz-0007dS-00 for simple@ietf.org; Wed, 12 Nov 2003 17:21:50 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hACMJkIc001331; Wed, 12 Nov 2003 16:19:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2B1FF.6020703@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 16:19:43 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I concur with Adam. The basic URI (not counting the list parameter) identifies an application that knows to do something with the list parameter. Some other application might just ignore the list parameter. Adam Roach wrote: > I would argue that, as with every other request you send, > the application behavior depends on the request URI. > > So, for example, I could deploy an application server in > the middle of the network that treats: > > INVITE sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com > SIP/2.0 > > ...very differently than... > > INVITE sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > /a > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, November 12, 2003 12:39 >>To: Markus.Isomaki@nokia.com >>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >>There seems to be an assumption here that sending an INVITE >>to an ad hoc >>list should create a conference. That is certainly one >>interpretation, >>but not the only possible one. If the ad hoc list server is a simple >>message exploder then you probably aren't going to get a conference. >> >>If you have a list of people and want to set up a conference >>there are >>other ways to do it, so trying to bend ad hoc list to do this >>may not be >>justified. >> >> Paul >> >>Markus.Isomaki@nokia.com wrote: >> >>>Hi, >>> >>>I believe the best way would be for them to subscribe to >> >>conference-state event package, if that is available. But I >>guess there is a bigger issue here: What is the relationship >>between a conference started through an exploder and a >>conference setup for with CPCP a la XCON. Is it possible to >>migrate from an exploder conference to CPCP-controllable one >>(given that the server supports CPCP, conference notification >>service etc.)? >> >>>I have yet another requirement for this ad hoc list / >> >>exploder solution. Especially in the case of MESSAGE to a >>list, it would be nice to be able to convey to the recipients >>the list of other recipients. It should be possible for the >>original sender to indicate this. It shouldn't be too hard to >>map the headers/payload from incoming to outgoing side for >>this purpose within the "exploder server". >> >>>Markus >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Dean Willis >>>>Sent: 12 November, 2003 16:56 >>>>To: Jonathan Rosenberg >>>>Cc: Simple WG >>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>> >>>> >>>> >>>> >>>> >>>>>I dont get this. I thought that an ad-hoc list would be >>>> >>>>scoped to the >>>> >>>> >>>>>subscription, in which case, there wouldnt be any other >>>> >>>>subscribers. Am >>>> >>>> >>>>>I missing something? >>>> >>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>>>conference. Would "members" of the list (i.e., participants in the >>>>conference) subscribe to the list, or to the conference in order to >>>>learn about changes to the participant set? >>>> >>>>-- >>>>Dean >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 >> > > > _______________________________________________ > 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-admin@ietf.org Wed Nov 12 22:09:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24308; Wed, 12 Nov 2003 22:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7rv-00049n-00; Wed, 12 Nov 2003 22:10:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7ru-00049k-00; Wed, 12 Nov 2003 22:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7ru-00067b-Dp; Wed, 12 Nov 2003 22:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7rV-00066z-0K for simple@optimus.ietf.org; Wed, 12 Nov 2003 22:09:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24299 for ; Wed, 12 Nov 2003 22:09:23 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7rR-00049W-00 for simple@ietf.org; Wed, 12 Nov 2003 22:09:33 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK7rR-00049T-00 for simple@ietf.org; Wed, 12 Nov 2003 22:09:33 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAD39XA25545 for ; Thu, 13 Nov 2003 05:09:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 05:09:31 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 05:09:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOpa2J++5MLJEmFQtmiliKXqioCPwAJbQRg To: , Cc: , , , X-OriginalArrivalTime: 13 Nov 2003 03:09:32.0522 (UTC) FILETIME=[8F4164A0:01C3A993] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 05:09:31 +0200 Content-Transfer-Encoding: quoted-printable Hi, Would you consider the decision whether the list contents are included = in the request sent by the application server as application logic, or = should this be explicitely signaled by the original sender?=20 In general it is not clear to me what kind of behaviours should be = standardized/signaled, and which are just left to each application to = decide. In fact I'm inclined to think that this kind of very basic = cases, i.e. conference establishment or B2BUA forking, should be made = explicit. More advanced/niche features, such as if the app. server sends = e-mail to people not reached, can be left to the imagination of the = developers. One of the reasons is that I would like the basic features = to work uniformly accross service providers. I believe this to be the = advantage of the "ordinary" users. Markus=20 > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 13 November, 2003 00:20 > To: Adam Roach > Cc: 'Paul Kyzivat'; Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] ad-hoc list subscriptions >=20 >=20 > I concur with Adam. The basic URI (not counting the list parameter)=20 > identifies an application that knows to do something with the list=20 > parameter. Some other application might just ignore the list=20 > parameter. >=20 > Adam Roach wrote: >=20 > > I would argue that, as with every other request you send, > > the application behavior depends on the request URI. > >=20 > > So, for example, I could deploy an application server in > > the middle of the network that treats: > >=20 > > INVITE=20 > sip:conference@example.com;list=3Dcid:cn35t8jf02@terminal.foo.com > > SIP/2.0 > >=20 > > ...very differently than... > >=20 > > INVITE=20 > sip:fork@example.com;list=3Dcid:cn35t8jf02@terminal.foo.com SIP/2.0 > >=20 > > /a > >=20 > >=20 > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Wednesday, November 12, 2003 12:39 > >>To: Markus.Isomaki@nokia.com > >>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com;=20 > >>simple@ietf.org > >>Subject: Re: [Simple] ad-hoc list subscriptions > >> > >> > >>There seems to be an assumption here that sending an INVITE=20 > >>to an ad hoc=20 > >>list should create a conference. That is certainly one=20 > >>interpretation,=20 > >>but not the only possible one. If the ad hoc list server is=20 > a simple=20 > >>message exploder then you probably aren't going to get a conference. > >> > >>If you have a list of people and want to set up a conference=20 > >>there are=20 > >>other ways to do it, so trying to bend ad hoc list to do this=20 > >>may not be=20 > >>justified. > >> > >> Paul > >> > >>Markus.Isomaki@nokia.com wrote: > >> > >>>Hi, > >>> > >>>I believe the best way would be for them to subscribe to=20 > >> > >>conference-state event package, if that is available. But I=20 > >>guess there is a bigger issue here: What is the relationship=20 > >>between a conference started through an exploder and a=20 > >>conference setup for with CPCP a la XCON. Is it possible to=20 > >>migrate from an exploder conference to CPCP-controllable one=20 > >>(given that the server supports CPCP, conference notification=20 > >>service etc.)? > >> > >>>I have yet another requirement for this ad hoc list /=20 > >> > >>exploder solution. Especially in the case of MESSAGE to a=20 > >>list, it would be nice to be able to convey to the recipients=20 > >>the list of other recipients. It should be possible for the=20 > >>original sender to indicate this. It shouldn't be too hard to=20 > >>map the headers/payload from incoming to outgoing side for=20 > >>this purpose within the "exploder server". > >> > >>>Markus=20 > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: simple-admin@ietf.org=20 > >> > >>[mailto:simple-admin@ietf.org]On Behalf Of > >> > >>>>ext Dean Willis > >>>>Sent: 12 November, 2003 16:56 > >>>>To: Jonathan Rosenberg > >>>>Cc: Simple WG > >>>>Subject: Re: [Simple] ad-hoc list subscriptions > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I dont get this. I thought that an ad-hoc list would be=20 > >>>> > >>>>scoped to the=20 > >>>> > >>>> > >>>>>subscription, in which case, there wouldnt be any other=20 > >>>> > >>>>subscribers. Am=20 > >>>> > >>>> > >>>>>I missing something? > >>>> > >>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc=20 > >>>>conference. Would "members" of the list (i.e.,=20 > participants in the=20 > >>>>conference) subscribe to the list, or to the conference=20 > in order to=20 > >>>>learn about changes to the participant set? > >>>> > >>>>-- > >>>>Dean > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 12 22:10:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24330 for ; Wed, 12 Nov 2003 22:10:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7rz-00068R-K6 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 22:10:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3A7rE023579 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 22:10:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7rz-00068E-GR for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:10:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24308; Wed, 12 Nov 2003 22:09:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7rv-00049n-00; Wed, 12 Nov 2003 22:10:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK7ru-00049k-00; Wed, 12 Nov 2003 22:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7ru-00067b-Dp; Wed, 12 Nov 2003 22:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK7rV-00066z-0K for simple@optimus.ietf.org; Wed, 12 Nov 2003 22:09:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24299 for ; Wed, 12 Nov 2003 22:09:23 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK7rR-00049W-00 for simple@ietf.org; Wed, 12 Nov 2003 22:09:33 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AK7rR-00049T-00 for simple@ietf.org; Wed, 12 Nov 2003 22:09:33 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAD39XA25545 for ; Thu, 13 Nov 2003 05:09:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 05:09:31 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 05:09:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOpa2J++5MLJEmFQtmiliKXqioCPwAJbQRg To: , Cc: , , , X-OriginalArrivalTime: 13 Nov 2003 03:09:32.0522 (UTC) FILETIME=[8F4164A0:01C3A993] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 05:09:31 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Would you consider the decision whether the list contents are included = in the request sent by the application server as application logic, or = should this be explicitely signaled by the original sender?=20 In general it is not clear to me what kind of behaviours should be = standardized/signaled, and which are just left to each application to = decide. In fact I'm inclined to think that this kind of very basic = cases, i.e. conference establishment or B2BUA forking, should be made = explicit. More advanced/niche features, such as if the app. server sends = e-mail to people not reached, can be left to the imagination of the = developers. One of the reasons is that I would like the basic features = to work uniformly accross service providers. I believe this to be the = advantage of the "ordinary" users. Markus=20 > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 13 November, 2003 00:20 > To: Adam Roach > Cc: 'Paul Kyzivat'; Isomaki Markus (NRC/Helsinki); > dean.willis@softarmor.com; Jonathan Rosenberg; simple@ietf.org > Subject: Re: [Simple] ad-hoc list subscriptions >=20 >=20 > I concur with Adam. The basic URI (not counting the list parameter)=20 > identifies an application that knows to do something with the list=20 > parameter. Some other application might just ignore the list=20 > parameter. >=20 > Adam Roach wrote: >=20 > > I would argue that, as with every other request you send, > > the application behavior depends on the request URI. > >=20 > > So, for example, I could deploy an application server in > > the middle of the network that treats: > >=20 > > INVITE=20 > sip:conference@example.com;list=3Dcid:cn35t8jf02@terminal.foo.com > > SIP/2.0 > >=20 > > ...very differently than... > >=20 > > INVITE=20 > sip:fork@example.com;list=3Dcid:cn35t8jf02@terminal.foo.com SIP/2.0 > >=20 > > /a > >=20 > >=20 > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: Wednesday, November 12, 2003 12:39 > >>To: Markus.Isomaki@nokia.com > >>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com;=20 > >>simple@ietf.org > >>Subject: Re: [Simple] ad-hoc list subscriptions > >> > >> > >>There seems to be an assumption here that sending an INVITE=20 > >>to an ad hoc=20 > >>list should create a conference. That is certainly one=20 > >>interpretation,=20 > >>but not the only possible one. If the ad hoc list server is=20 > a simple=20 > >>message exploder then you probably aren't going to get a conference. > >> > >>If you have a list of people and want to set up a conference=20 > >>there are=20 > >>other ways to do it, so trying to bend ad hoc list to do this=20 > >>may not be=20 > >>justified. > >> > >> Paul > >> > >>Markus.Isomaki@nokia.com wrote: > >> > >>>Hi, > >>> > >>>I believe the best way would be for them to subscribe to=20 > >> > >>conference-state event package, if that is available. But I=20 > >>guess there is a bigger issue here: What is the relationship=20 > >>between a conference started through an exploder and a=20 > >>conference setup for with CPCP a la XCON. Is it possible to=20 > >>migrate from an exploder conference to CPCP-controllable one=20 > >>(given that the server supports CPCP, conference notification=20 > >>service etc.)? > >> > >>>I have yet another requirement for this ad hoc list /=20 > >> > >>exploder solution. Especially in the case of MESSAGE to a=20 > >>list, it would be nice to be able to convey to the recipients=20 > >>the list of other recipients. It should be possible for the=20 > >>original sender to indicate this. It shouldn't be too hard to=20 > >>map the headers/payload from incoming to outgoing side for=20 > >>this purpose within the "exploder server". > >> > >>>Markus=20 > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: simple-admin@ietf.org=20 > >> > >>[mailto:simple-admin@ietf.org]On Behalf Of > >> > >>>>ext Dean Willis > >>>>Sent: 12 November, 2003 16:56 > >>>>To: Jonathan Rosenberg > >>>>Cc: Simple WG > >>>>Subject: Re: [Simple] ad-hoc list subscriptions > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>I dont get this. I thought that an ad-hoc list would be=20 > >>>> > >>>>scoped to the=20 > >>>> > >>>> > >>>>>subscription, in which case, there wouldnt be any other=20 > >>>> > >>>>subscribers. Am=20 > >>>> > >>>> > >>>>>I missing something? > >>>> > >>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc=20 > >>>>conference. Would "members" of the list (i.e.,=20 > participants in the=20 > >>>>conference) subscribe to the list, or to the conference=20 > in order to=20 > >>>>learn about changes to the participant set? > >>>> > >>>>-- > >>>>Dean > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 12 22:22:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24646; Wed, 12 Nov 2003 22:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK84W-0004J5-00; Wed, 12 Nov 2003 22:23:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK84W-0004J2-00; Wed, 12 Nov 2003 22:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK84T-0006RB-OB; Wed, 12 Nov 2003 22:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK84E-0006Ql-Qd for simple@optimus.ietf.org; Wed, 12 Nov 2003 22:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24612 for ; Wed, 12 Nov 2003 22:22:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK84B-0004Id-00 for simple@ietf.org; Wed, 12 Nov 2003 22:22:43 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AK84A-0004IU-00 for simple@ietf.org; Wed, 12 Nov 2003 22:22:42 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAD3MDIc027356; Wed, 12 Nov 2003 21:22:27 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2F8E1.1020203@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: adam@dynamicsoft.com, pkyzivat@cisco.com, dean.willis@softarmor.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 21:22:09 -0600 Content-Transfer-Encoding: 7bit First, just for clarity's sake, I did not intend for the word "application" to indicate any value judgement about whether it should be standardized or not. More inline: Markus.Isomaki@nokia.com wrote: > Hi, > > Would you consider the decision whether the list contents are included in the request sent by the application server as application logic, or should this be explicitely signaled by the original sender? > Assuming you actually mean should we standardize whether the app server copies the list into the resulting "exploded" requests, I think it has to be taken on a case by case basis based on the semantics of the "exploder" application. For example, it may make sense to signal the choice if exploding MESSAGE, but I can't think of any use for doing that for SUBSCRIBE. That does not mean that we cannot standardize specific applications. > In general it is not clear to me what kind of behaviours should be standardized/signaled, and which are just left to each application to decide. In fact I'm inclined to think that this kind of very basic cases, i.e. conference establishment or B2BUA forking, should be made explicit. More advanced/niche features, such as if the app. server sends e-mail to people not reached, can be left to the imagination of the developers. One of the reasons is that I would like the basic features to work uniformly accross service providers. I believe this to be the advantage of the "ordinary" users. > > Markus > > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 13 November, 2003 00:20 >>To: Adam Roach >>Cc: 'Paul Kyzivat'; Isomaki Markus (NRC/Helsinki); >>dean.willis@softarmor.com; Jonathan Rosenberg; simple@ietf.org >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >>I concur with Adam. The basic URI (not counting the list parameter) >>identifies an application that knows to do something with the list >>parameter. Some other application might just ignore the list >>parameter. >> >>Adam Roach wrote: >> >> >>>I would argue that, as with every other request you send, >>>the application behavior depends on the request URI. >>> >>>So, for example, I could deploy an application server in >>>the middle of the network that treats: >>> >>>INVITE >> >>sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com >> >>>SIP/2.0 >>> >>>...very differently than... >>> >>>INVITE >> >>sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 >> >>>/a >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: Wednesday, November 12, 2003 12:39 >>>>To: Markus.Isomaki@nokia.com >>>>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; >>>>simple@ietf.org >>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>> >>>> >>>>There seems to be an assumption here that sending an INVITE >>>>to an ad hoc >>>>list should create a conference. That is certainly one >>>>interpretation, >>>>but not the only possible one. If the ad hoc list server is >> >>a simple >> >>>>message exploder then you probably aren't going to get a conference. >>>> >>>>If you have a list of people and want to set up a conference >>>>there are >>>>other ways to do it, so trying to bend ad hoc list to do this >>>>may not be >>>>justified. >>>> >>>> Paul >>>> >>>>Markus.Isomaki@nokia.com wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>I believe the best way would be for them to subscribe to >>>> >>>>conference-state event package, if that is available. But I >>>>guess there is a bigger issue here: What is the relationship >>>>between a conference started through an exploder and a >>>>conference setup for with CPCP a la XCON. Is it possible to >>>>migrate from an exploder conference to CPCP-controllable one >>>>(given that the server supports CPCP, conference notification >>>>service etc.)? >>>> >>>> >>>>>I have yet another requirement for this ad hoc list / >>>> >>>>exploder solution. Especially in the case of MESSAGE to a >>>>list, it would be nice to be able to convey to the recipients >>>>the list of other recipients. It should be possible for the >>>>original sender to indicate this. It shouldn't be too hard to >>>>map the headers/payload from incoming to outgoing side for >>>>this purpose within the "exploder server". >>>> >>>> >>>>>Markus >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org >>>> >>>>[mailto:simple-admin@ietf.org]On Behalf Of >>>> >>>> >>>>>>ext Dean Willis >>>>>>Sent: 12 November, 2003 16:56 >>>>>>To: Jonathan Rosenberg >>>>>>Cc: Simple WG >>>>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I dont get this. I thought that an ad-hoc list would be >>>>>> >>>>>>scoped to the >>>>>> >>>>>> >>>>>> >>>>>>>subscription, in which case, there wouldnt be any other >>>>>> >>>>>>subscribers. Am >>>>>> >>>>>> >>>>>> >>>>>>>I missing something? >>>>>> >>>>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>>>>>conference. Would "members" of the list (i.e., >> >>participants in the >> >>>>>>conference) subscribe to the list, or to the conference >> >>in order to >> >>>>>>learn about changes to the participant set? >>>>>> >>>>>>-- >>>>>>Dean >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>> >>> >>> >>>_______________________________________________ >>>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 exim@www1.ietf.org Wed Nov 12 22:23:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24665 for ; Wed, 12 Nov 2003 22:23:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK84b-0006U5-9V for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 22:23:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3N9cO024924 for simple-archive@odin.ietf.org; Wed, 12 Nov 2003 22:23:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK84b-0006Tv-5M for simple-web-archive@optimus.ietf.org; Wed, 12 Nov 2003 22:23:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24646; Wed, 12 Nov 2003 22:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK84W-0004J5-00; Wed, 12 Nov 2003 22:23:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AK84W-0004J2-00; Wed, 12 Nov 2003 22:23:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK84T-0006RB-OB; Wed, 12 Nov 2003 22:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK84E-0006Ql-Qd for simple@optimus.ietf.org; Wed, 12 Nov 2003 22:22:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24612 for ; Wed, 12 Nov 2003 22:22:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK84B-0004Id-00 for simple@ietf.org; Wed, 12 Nov 2003 22:22:43 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AK84A-0004IU-00 for simple@ietf.org; Wed, 12 Nov 2003 22:22:42 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAD3MDIc027356; Wed, 12 Nov 2003 21:22:27 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2F8E1.1020203@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: adam@dynamicsoft.com, pkyzivat@cisco.com, dean.willis@softarmor.com, jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 12 Nov 2003 21:22:09 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit First, just for clarity's sake, I did not intend for the word "application" to indicate any value judgement about whether it should be standardized or not. More inline: Markus.Isomaki@nokia.com wrote: > Hi, > > Would you consider the decision whether the list contents are included in the request sent by the application server as application logic, or should this be explicitely signaled by the original sender? > Assuming you actually mean should we standardize whether the app server copies the list into the resulting "exploded" requests, I think it has to be taken on a case by case basis based on the semantics of the "exploder" application. For example, it may make sense to signal the choice if exploding MESSAGE, but I can't think of any use for doing that for SUBSCRIBE. That does not mean that we cannot standardize specific applications. > In general it is not clear to me what kind of behaviours should be standardized/signaled, and which are just left to each application to decide. In fact I'm inclined to think that this kind of very basic cases, i.e. conference establishment or B2BUA forking, should be made explicit. More advanced/niche features, such as if the app. server sends e-mail to people not reached, can be left to the imagination of the developers. One of the reasons is that I would like the basic features to work uniformly accross service providers. I believe this to be the advantage of the "ordinary" users. > > Markus > > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 13 November, 2003 00:20 >>To: Adam Roach >>Cc: 'Paul Kyzivat'; Isomaki Markus (NRC/Helsinki); >>dean.willis@softarmor.com; Jonathan Rosenberg; simple@ietf.org >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >>I concur with Adam. The basic URI (not counting the list parameter) >>identifies an application that knows to do something with the list >>parameter. Some other application might just ignore the list >>parameter. >> >>Adam Roach wrote: >> >> >>>I would argue that, as with every other request you send, >>>the application behavior depends on the request URI. >>> >>>So, for example, I could deploy an application server in >>>the middle of the network that treats: >>> >>>INVITE >> >>sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com >> >>>SIP/2.0 >>> >>>...very differently than... >>> >>>INVITE >> >>sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 >> >>>/a >>> >>> >>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: Wednesday, November 12, 2003 12:39 >>>>To: Markus.Isomaki@nokia.com >>>>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; >>>>simple@ietf.org >>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>> >>>> >>>>There seems to be an assumption here that sending an INVITE >>>>to an ad hoc >>>>list should create a conference. That is certainly one >>>>interpretation, >>>>but not the only possible one. If the ad hoc list server is >> >>a simple >> >>>>message exploder then you probably aren't going to get a conference. >>>> >>>>If you have a list of people and want to set up a conference >>>>there are >>>>other ways to do it, so trying to bend ad hoc list to do this >>>>may not be >>>>justified. >>>> >>>> Paul >>>> >>>>Markus.Isomaki@nokia.com wrote: >>>> >>>> >>>>>Hi, >>>>> >>>>>I believe the best way would be for them to subscribe to >>>> >>>>conference-state event package, if that is available. But I >>>>guess there is a bigger issue here: What is the relationship >>>>between a conference started through an exploder and a >>>>conference setup for with CPCP a la XCON. Is it possible to >>>>migrate from an exploder conference to CPCP-controllable one >>>>(given that the server supports CPCP, conference notification >>>>service etc.)? >>>> >>>> >>>>>I have yet another requirement for this ad hoc list / >>>> >>>>exploder solution. Especially in the case of MESSAGE to a >>>>list, it would be nice to be able to convey to the recipients >>>>the list of other recipients. It should be possible for the >>>>original sender to indicate this. It shouldn't be too hard to >>>>map the headers/payload from incoming to outgoing side for >>>>this purpose within the "exploder server". >>>> >>>> >>>>>Markus >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org >>>> >>>>[mailto:simple-admin@ietf.org]On Behalf Of >>>> >>>> >>>>>>ext Dean Willis >>>>>>Sent: 12 November, 2003 16:56 >>>>>>To: Jonathan Rosenberg >>>>>>Cc: Simple WG >>>>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I dont get this. I thought that an ad-hoc list would be >>>>>> >>>>>>scoped to the >>>>>> >>>>>> >>>>>> >>>>>>>subscription, in which case, there wouldnt be any other >>>>>> >>>>>>subscribers. Am >>>>>> >>>>>> >>>>>> >>>>>>>I missing something? >>>>>> >>>>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>>>>>conference. Would "members" of the list (i.e., >> >>participants in the >> >>>>>>conference) subscribe to the list, or to the conference >> >>in order to >> >>>>>>learn about changes to the participant set? >>>>>> >>>>>>-- >>>>>>Dean >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>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 >>>> >>> >>> >>>_______________________________________________ >>>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-admin@ietf.org Thu Nov 13 03:15:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16020; Thu, 13 Nov 2003 03:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCe4-0000cc-00; Thu, 13 Nov 2003 03:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCe3-0000cZ-00; Thu, 13 Nov 2003 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCe1-0000lo-C9; Thu, 13 Nov 2003 03:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCdk-0000jB-O4 for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16011 for ; Thu, 13 Nov 2003 03:15:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCdi-0000aK-00 for simple@ietf.org; Thu, 13 Nov 2003 03:15:42 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCdh-0000a1-00 for simple@ietf.org; Thu, 13 Nov 2003 03:15:41 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8FEca016551; Thu, 13 Nov 2003 03:15:14 -0500 (EST) Message-ID: <3FB33D8F.7030700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-01 References: <2038BCC78B1AD641891A0D1AE133DBB701797375@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797375@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:15:11 -0500 Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > Overall, I think the document is ready. Some minor comments: > > - Resource Interdependency: After a server has populated a element > or attribute, like the URI for a list, how does this information > get communicated to the client (how does the client learn of such > information)? Does the server fill it in before the 200 Ok is > returned and body of the response contains the xml document (I > don't think this is a good solution)? No. The client would do a separate GET afterwards. This is not clear. I tried to add some text on it, but I think its not there yet. > > - Creating a new document: must the document have file type of > .xml? In the example in section 6.1, should mybuddies be > mybuddies.xml? I dont think it matters that much, as long as we are clear whether the extension should be there or not. My leaning is towards yes. > > - Content-type: I think defining a content-type for xcap is needed > for creating/replacing elements and attributes. It is better than > using text/plain as currently shown in the examples. I would be inclined to use application+xml whenever the body is a valid XML document, which is all cases except where you are fetching or putting attributes. In those cases, text/plain seems reasonable. I dont see what value we gain in registering a new MIME type. > > - Replacing an element/attribute: It might be useful to indicate > that modifying an element value of an element is not possible, > especially if that element has attributes. The whole element, > including its attributes must be replaced. OK, will do. > > - E-tags: If an element or attribute has been replaced or deleted, > how does a client learn of such change? A client can never learn of > a change unless is performs a GET and examines the etag. This is a good question. Jari had a similar one, and I'll discuss in a reply to that mail. > BTW, > whatever happened to the event package for xcap? I didnt rev it. I think its much more controversial. There are big, hard questions, like whether or not this is the same or different as the config framework package. Indeed, I would propose that we should move forward with the main xcap spec and the list and auth packages first, and work on the event package separate. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:16:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16065 for ; Thu, 13 Nov 2003 03:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCe8-0000ma-3P for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8G8B9003009 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:16:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCe7-0000mS-Em for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16020; Thu, 13 Nov 2003 03:15:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCe4-0000cc-00; Thu, 13 Nov 2003 03:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCe3-0000cZ-00; Thu, 13 Nov 2003 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCe1-0000lo-C9; Thu, 13 Nov 2003 03:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCdk-0000jB-O4 for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:15:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16011 for ; Thu, 13 Nov 2003 03:15:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCdi-0000aK-00 for simple@ietf.org; Thu, 13 Nov 2003 03:15:42 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCdh-0000a1-00 for simple@ietf.org; Thu, 13 Nov 2003 03:15:41 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8FEca016551; Thu, 13 Nov 2003 03:15:14 -0500 (EST) Message-ID: <3FB33D8F.7030700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-01 References: <2038BCC78B1AD641891A0D1AE133DBB701797375@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797375@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:15:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. hisham.khartabil@nokia.com wrote: > Overall, I think the document is ready. Some minor comments: > > - Resource Interdependency: After a server has populated a element > or attribute, like the URI for a list, how does this information > get communicated to the client (how does the client learn of such > information)? Does the server fill it in before the 200 Ok is > returned and body of the response contains the xml document (I > don't think this is a good solution)? No. The client would do a separate GET afterwards. This is not clear. I tried to add some text on it, but I think its not there yet. > > - Creating a new document: must the document have file type of > .xml? In the example in section 6.1, should mybuddies be > mybuddies.xml? I dont think it matters that much, as long as we are clear whether the extension should be there or not. My leaning is towards yes. > > - Content-type: I think defining a content-type for xcap is needed > for creating/replacing elements and attributes. It is better than > using text/plain as currently shown in the examples. I would be inclined to use application+xml whenever the body is a valid XML document, which is all cases except where you are fetching or putting attributes. In those cases, text/plain seems reasonable. I dont see what value we gain in registering a new MIME type. > > - Replacing an element/attribute: It might be useful to indicate > that modifying an element value of an element is not possible, > especially if that element has attributes. The whole element, > including its attributes must be replaced. OK, will do. > > - E-tags: If an element or attribute has been replaced or deleted, > how does a client learn of such change? A client can never learn of > a change unless is performs a GET and examines the etag. This is a good question. Jari had a similar one, and I'll discuss in a reply to that mail. > BTW, > whatever happened to the event package for xcap? I didnt rev it. I think its much more controversial. There are big, hard questions, like whether or not this is the same or different as the config framework package. Indeed, I would propose that we should move forward with the main xcap spec and the list and auth packages first, and work on the event package separate. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 03:25:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16279; Thu, 13 Nov 2003 03:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCnj-0000jJ-00; Thu, 13 Nov 2003 03:26:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCnj-0000jG-00; Thu, 13 Nov 2003 03:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCni-0001JD-Iv; Thu, 13 Nov 2003 03:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCmu-0001Fw-JG for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16250 for ; Thu, 13 Nov 2003 03:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCms-0000id-00 for simple@ietf.org; Thu, 13 Nov 2003 03:25:10 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCmr-0000iH-00 for simple@ietf.org; Thu, 13 Nov 2003 03:25:09 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8Ohca016555; Thu, 13 Nov 2003 03:24:43 -0500 (EST) Message-ID: <3FB33FC7.3060506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen CC: simple@ietf.org Subject: Re: [Simple] Managing XCAP Etags References: <3FA75F19.8080802@nokia.com> In-Reply-To: <3FA75F19.8080802@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:24:39 -0500 Content-Transfer-Encoding: 7bit This is a good question. I think that, when there is a modification to a component of the document, the server would assign the same Etag to all of the ancestor and descendant components. This way, if the client is the only one ever manipulating the document, it knows what the various etags are without having to query them. That said, I think its worth considering whether this is just too complicated or not. If we take your proposed route, and just maintain an etag for the document, its definitely simpler. The drawback is that it will become very hard for two users to separately modify different subtrees in the same document. Each time one makes a change, the other will need to fetch the whole document to apply there change. Is that a problem? Not clear. For the current application usages on the table in SIMPLE, I would say no. Indeed, if the scope of xcap is to worry about the provisioned data for a user, then its unlikely in general that there will be multiple clients in play at once, since the scope by definition is provisioned data for a user. Some of the other conceived usages, such as CPCP, consider cases where the data is about a conference, and potentially many users might be modifying it at the same time. That said, I am inclined to favor simplicity here, and accept your suggestion to maintain an Etag on the entire document, rather than full set of components. I'll also be discussing this during the SIMPLE meeting tomorrow afternoon. Thanks, Jonathan R. Jari Urpalainen wrote: > Hi all, > > As entity tags should be updated according to current XCAP-draft by > element/node/attribute basis, synchronization between the client and > server is fairly complicated. While I understand that the aim is to > allow fine-grained partial updates to the xml-documents, but after many > partial updates one document may have a lot of "tree-like" ETag > metadata. The problem is how to get this metadata to the client ? If > you havn't followed the history of the document, i.e you are fetching > some new document with http get and you'll receive e.g. only the root > Etag then. What about the other Etags within xml-tree ? Certainly, you > could get them by XPATH-queries according to the document, but that is > way too ugly. Instead, I'll propose that only document based Etag is > used, as it allows a simple integrity test for partial updates and is > also much simpler to implement. > > BR, > Jari Urpalainen > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:26:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16330 for ; Thu, 13 Nov 2003 03:26:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCnp-0001NL-Pj for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:26:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8Q9Ys005285 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCnn-0001Jx-GE for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:26:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16279; Thu, 13 Nov 2003 03:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCnj-0000jJ-00; Thu, 13 Nov 2003 03:26:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCnj-0000jG-00; Thu, 13 Nov 2003 03:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCni-0001JD-Iv; Thu, 13 Nov 2003 03:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCmu-0001Fw-JG for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:25:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16250 for ; Thu, 13 Nov 2003 03:25:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCms-0000id-00 for simple@ietf.org; Thu, 13 Nov 2003 03:25:10 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCmr-0000iH-00 for simple@ietf.org; Thu, 13 Nov 2003 03:25:09 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8Ohca016555; Thu, 13 Nov 2003 03:24:43 -0500 (EST) Message-ID: <3FB33FC7.3060506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Urpalainen CC: simple@ietf.org Subject: Re: [Simple] Managing XCAP Etags References: <3FA75F19.8080802@nokia.com> In-Reply-To: <3FA75F19.8080802@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:24:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a good question. I think that, when there is a modification to a component of the document, the server would assign the same Etag to all of the ancestor and descendant components. This way, if the client is the only one ever manipulating the document, it knows what the various etags are without having to query them. That said, I think its worth considering whether this is just too complicated or not. If we take your proposed route, and just maintain an etag for the document, its definitely simpler. The drawback is that it will become very hard for two users to separately modify different subtrees in the same document. Each time one makes a change, the other will need to fetch the whole document to apply there change. Is that a problem? Not clear. For the current application usages on the table in SIMPLE, I would say no. Indeed, if the scope of xcap is to worry about the provisioned data for a user, then its unlikely in general that there will be multiple clients in play at once, since the scope by definition is provisioned data for a user. Some of the other conceived usages, such as CPCP, consider cases where the data is about a conference, and potentially many users might be modifying it at the same time. That said, I am inclined to favor simplicity here, and accept your suggestion to maintain an Etag on the entire document, rather than full set of components. I'll also be discussing this during the SIMPLE meeting tomorrow afternoon. Thanks, Jonathan R. Jari Urpalainen wrote: > Hi all, > > As entity tags should be updated according to current XCAP-draft by > element/node/attribute basis, synchronization between the client and > server is fairly complicated. While I understand that the aim is to > allow fine-grained partial updates to the xml-documents, but after many > partial updates one document may have a lot of "tree-like" ETag > metadata. The problem is how to get this metadata to the client ? If > you havn't followed the history of the document, i.e you are fetching > some new document with http get and you'll receive e.g. only the root > Etag then. What about the other Etags within xml-tree ? Certainly, you > could get them by XPATH-queries according to the document, but that is > way too ugly. Instead, I'll propose that only document based Etag is > used, as it allows a simple integrity test for partial updates and is > also much simpler to implement. > > BR, > Jari Urpalainen > > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 03:33:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16437; Thu, 13 Nov 2003 03:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCvT-0000p3-00; Thu, 13 Nov 2003 03:34:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCvS-0000p0-00; Thu, 13 Nov 2003 03:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCvR-0001aB-8b; Thu, 13 Nov 2003 03:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCv4-0001YO-WF for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16431 for ; Thu, 13 Nov 2003 03:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCv2-0000oo-00 for simple@ietf.org; Thu, 13 Nov 2003 03:33:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCv2-0000oi-00 for simple@ietf.org; Thu, 13 Nov 2003 03:33:36 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8X9ca016558; Thu, 13 Nov 2003 03:33:09 -0500 (EST) Message-ID: <3FB341C2.2020407@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-01.txt -> comments References: <902B96A872B24840B48412649C0E8A42012FD7D3@trebe003.europe.nokia.com> In-Reply-To: <902B96A872B24840B48412649C0E8A42012FD7D3@trebe003.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:33:06 -0500 Content-Transfer-Encoding: 7bit Thanks for your comments. Responses inline. eva-maria.leppanen@nokia.com wrote: > Hi, > > Thanks for the new version of the XCAP draft! It was nice to see > that it was still improved, and more "exact" than the previous > version. I have only a couple of comments for the draft. > > I think that there could be more exact definition on what is > exactly the "real" content to be handled by the following three > operations: - 6.5. "Creating a new element" This chapter says that > "The content in the request MUST be an XML element." However, > shouldn't it state that "the content is an XML element and > associated content (including children elements)" OR "the content > is the portion of the XML document starding with the left bracket > of the begin tag of the element, ending with the right bracket of > the end tag of the element." as said in the later chapters > concerning the PUT and/or GET operations? Yes, good idea. I will use the latter text. As you say, I have already used that elsewhere. > > - 6.6. "Replacing an element in the document The same comment as > for the "creating a new element" applies also to this chapter. Sure, but this section refers to 6.5 for most of the details. So, I think a discussion in 6.5 alone is sufficient. > > - 6.7. "Delete an Element * The chapter says "...containing the > elements to be deleted": is it possible to delete elements from > several parts of the document using one "delete an element" > operation or should the node selector point to only one element? > This could be clarified in the chapter. One element. I will clarify. > > > * the same comments as for > the chapter 6.5 also applies here: shouldn't the "delete" remove > the element plus its sub-tree? Yes, I will clarify. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:34:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16464 for ; Thu, 13 Nov 2003 03:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCvZ-0001c9-Qd for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:34:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8Y92o006133 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:34:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCvW-0001aq-H7 for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:34:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16437; Thu, 13 Nov 2003 03:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCvT-0000p3-00; Thu, 13 Nov 2003 03:34:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCvS-0000p0-00; Thu, 13 Nov 2003 03:34:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCvR-0001aB-8b; Thu, 13 Nov 2003 03:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCv4-0001YO-WF for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16431 for ; Thu, 13 Nov 2003 03:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCv2-0000oo-00 for simple@ietf.org; Thu, 13 Nov 2003 03:33:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCv2-0000oi-00 for simple@ietf.org; Thu, 13 Nov 2003 03:33:36 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8X9ca016558; Thu, 13 Nov 2003 03:33:09 -0500 (EST) Message-ID: <3FB341C2.2020407@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eva-maria.leppanen@nokia.com CC: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-xcap-01.txt -> comments References: <902B96A872B24840B48412649C0E8A42012FD7D3@trebe003.europe.nokia.com> In-Reply-To: <902B96A872B24840B48412649C0E8A42012FD7D3@trebe003.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:33:06 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for your comments. Responses inline. eva-maria.leppanen@nokia.com wrote: > Hi, > > Thanks for the new version of the XCAP draft! It was nice to see > that it was still improved, and more "exact" than the previous > version. I have only a couple of comments for the draft. > > I think that there could be more exact definition on what is > exactly the "real" content to be handled by the following three > operations: - 6.5. "Creating a new element" This chapter says that > "The content in the request MUST be an XML element." However, > shouldn't it state that "the content is an XML element and > associated content (including children elements)" OR "the content > is the portion of the XML document starding with the left bracket > of the begin tag of the element, ending with the right bracket of > the end tag of the element." as said in the later chapters > concerning the PUT and/or GET operations? Yes, good idea. I will use the latter text. As you say, I have already used that elsewhere. > > - 6.6. "Replacing an element in the document The same comment as > for the "creating a new element" applies also to this chapter. Sure, but this section refers to 6.5 for most of the details. So, I think a discussion in 6.5 alone is sufficient. > > - 6.7. "Delete an Element * The chapter says "...containing the > elements to be deleted": is it possible to delete elements from > several parts of the document using one "delete an element" > operation or should the node selector point to only one element? > This could be clarified in the chapter. One element. I will clarify. > > > * the same comments as for > the chapter 6.5 also applies here: shouldn't the "delete" remove > the element plus its sub-tree? Yes, I will clarify. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 03:36:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16512; Thu, 13 Nov 2003 03:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCyO-0000qc-00; Thu, 13 Nov 2003 03:37:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCyO-0000qZ-00; Thu, 13 Nov 2003 03:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCyL-0001l6-OQ; Thu, 13 Nov 2003 03:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCxy-0001kH-Co for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16502 for ; Thu, 13 Nov 2003 03:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCxv-0000q2-00 for simple@ietf.org; Thu, 13 Nov 2003 03:36:35 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCxv-0000pb-00 for simple@ietf.org; Thu, 13 Nov 2003 03:36:35 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8Z7ca016561; Thu, 13 Nov 2003 03:35:08 -0500 (EST) Message-ID: <3FB34238.60700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: simple@ietf.org References: <313680C9A886D511A06000204840E1CF070B6087@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6087@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Nit in xcap-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:35:04 -0500 Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > In the ABNF in 5.2, there are definitions repeated for by-pos and by-attr. Actually, its by-pos and position, but thanks. > Also, double checking that the intention on these parameters is that > no whitespace is allowed anywhere. Yes. Because they appear in URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:37:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16543 for ; Thu, 13 Nov 2003 03:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCyT-0001q8-RF for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8b99q007055 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCyS-0001pd-Fi for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16512; Thu, 13 Nov 2003 03:36:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCyO-0000qc-00; Thu, 13 Nov 2003 03:37:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKCyO-0000qZ-00; Thu, 13 Nov 2003 03:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCyL-0001l6-OQ; Thu, 13 Nov 2003 03:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKCxy-0001kH-Co for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:36:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16502 for ; Thu, 13 Nov 2003 03:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKCxv-0000q2-00 for simple@ietf.org; Thu, 13 Nov 2003 03:36:35 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKCxv-0000pb-00 for simple@ietf.org; Thu, 13 Nov 2003 03:36:35 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8Z7ca016561; Thu, 13 Nov 2003 03:35:08 -0500 (EST) Message-ID: <3FB34238.60700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rosen, Brian" CC: simple@ietf.org References: <313680C9A886D511A06000204840E1CF070B6087@whq-msgusr-02.pit.comms.marconi.com> In-Reply-To: <313680C9A886D511A06000204840E1CF070B6087@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Nit in xcap-01 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:35:04 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rosen, Brian wrote: > In the ABNF in 5.2, there are definitions repeated for by-pos and by-attr. Actually, its by-pos and position, but thanks. > Also, double checking that the intention on these parameters is that > no whitespace is allowed anywhere. Yes. Because they appear in URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 03:40:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16593; Thu, 13 Nov 2003 03:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKD2E-0000ri-00; Thu, 13 Nov 2003 03:41:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKD2E-0000rf-00; Thu, 13 Nov 2003 03:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKD2E-0002D6-Bu; Thu, 13 Nov 2003 03:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKD1K-0002Ar-V8 for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16576 for ; Thu, 13 Nov 2003 03:39:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKD1I-0000rJ-00 for simple@ietf.org; Thu, 13 Nov 2003 03:40:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKD1H-0000r8-00 for simple@ietf.org; Thu, 13 Nov 2003 03:40:03 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8dbca016565; Thu, 13 Nov 2003 03:39:37 -0500 (EST) Message-ID: <3FB34346.6030805@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: simple@ietf.org References: <3FA2B13B.6010401@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:39:34 -0500 Content-Transfer-Encoding: 7bit inline. Scott Lawrence wrote: > Jonathan Rosenberg writes: > > >>It had also been proposed to simply continue to use the "/" hierarchy all >>the way down into the XML document, i.e.: >> >>http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/ >> resource-list[@id="assd99"] >> >>where the last two components of the path identify XML elements. I didnt >>like this, since practically speaking, implementations are likely going to >>want to use the filesystem or DB to retrieve a specific document, and then >>use some XML processing to retrieve an element or attribute. So, knowing >>where the breakpoint is in the URI is helpful, I think. > > > I prefer the path approach, actually, specifically because it hides > the implementation detail - that's none of the clients business, and > the server side can do the split anyway. I suppose, though it would be nice if there was a clean separator to help that. With the path approach, the server has to know, through configuration or otherwise, where the break is. That may not be a big deal. However, there is another issue which may really require us to go this way. Its something you pointed out previously, and which Lisa talked to me about tonight. PRoxies and caches are very likely to be confused by the parameters in the GET, since they are sometimes stripped in the process of caching. Worse yet, you mentioned that some servers will be confused, or possibly not support, query parameters in PUT. If it doesnt work with existing servers, proxies or caches, thats a show-stopper to me. So, I am inclined to go for the path approach for this reason. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:41:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16613 for ; Thu, 13 Nov 2003 03:41:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKD2J-0002G1-RK for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8f7DF008623 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKD2I-0002Dh-KB for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:41:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16593; Thu, 13 Nov 2003 03:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKD2E-0000ri-00; Thu, 13 Nov 2003 03:41:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKD2E-0000rf-00; Thu, 13 Nov 2003 03:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKD2E-0002D6-Bu; Thu, 13 Nov 2003 03:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKD1K-0002Ar-V8 for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16576 for ; Thu, 13 Nov 2003 03:39:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKD1I-0000rJ-00 for simple@ietf.org; Thu, 13 Nov 2003 03:40:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKD1H-0000r8-00 for simple@ietf.org; Thu, 13 Nov 2003 03:40:03 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8dbca016565; Thu, 13 Nov 2003 03:39:37 -0500 (EST) Message-ID: <3FB34346.6030805@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: simple@ietf.org References: <3FA2B13B.6010401@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: draft-ietf-simple-xcap-00 comments Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:39:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Scott Lawrence wrote: > Jonathan Rosenberg writes: > > >>It had also been proposed to simply continue to use the "/" hierarchy all >>the way down into the XML document, i.e.: >> >>http://xcap.server.com/resource-lists/users/joe/my-buddies/resource-lists/ >> resource-list[@id="assd99"] >> >>where the last two components of the path identify XML elements. I didnt >>like this, since practically speaking, implementations are likely going to >>want to use the filesystem or DB to retrieve a specific document, and then >>use some XML processing to retrieve an element or attribute. So, knowing >>where the breakpoint is in the URI is helpful, I think. > > > I prefer the path approach, actually, specifically because it hides > the implementation detail - that's none of the clients business, and > the server side can do the split anyway. I suppose, though it would be nice if there was a clean separator to help that. With the path approach, the server has to know, through configuration or otherwise, where the break is. That may not be a big deal. However, there is another issue which may really require us to go this way. Its something you pointed out previously, and which Lisa talked to me about tonight. PRoxies and caches are very likely to be confused by the parameters in the GET, since they are sometimes stripped in the process of caching. Worse yet, you mentioned that some servers will be confused, or possibly not support, query parameters in PUT. If it doesnt work with existing servers, proxies or caches, thats a show-stopper to me. So, I am inclined to go for the path approach for this reason. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 03:56:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17108; Thu, 13 Nov 2003 03:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDGq-00016r-00; Thu, 13 Nov 2003 03:56:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDGq-00016o-00; Thu, 13 Nov 2003 03:56:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGk-0002rx-Nd; Thu, 13 Nov 2003 03:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDG9-0002pY-KF for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17044 for ; Thu, 13 Nov 2003 03:55:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDG6-00015T-00 for simple@ietf.org; Thu, 13 Nov 2003 03:55:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDG6-00014k-00 for simple@ietf.org; Thu, 13 Nov 2003 03:55:22 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8stca016572; Thu, 13 Nov 2003 03:54:55 -0500 (EST) Message-ID: <3FB346DC.8060009@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] XCAP comments References: <3FAFC585.4050107@nokia.com> In-Reply-To: <3FAFC585.4050107@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:54:52 -0500 Content-Transfer-Encoding: 7bit inline. Aki Niemi wrote: > Hi, > > Overall, I like XCAP - it's elegant and well written. Thanks! > My comments are > nothing major, but mostly nits and such. > > Cheers, > Aki > > --- > > - Chapter 4, paragraph beginning with "Resource Interdependencies", last > sentence says: > > Concretely, > this means that, after the server modifies the data, the entity > tags are updated as if the client had made the change itself. > > Does this mean that if the server changes something as a result of the > XCAP operation, the change will show as one made by the client? No. This text is not clear at all (I think Hisham commented on it too). It means that, the server effectively acts like *another* client. So, if the actual client tried to do a PUT with If-Match on the Etag, it would fail. It needs to fetch the doc to get the update. > Is that > the right way to do it, because in effect this would not require the > client to fetch this data, as it would seem like something already > up-to-date? The client is required to fetch it, but the etags will make it clear that the client does not have an up to date copy. > > I think the proper thing to do would be to make the etag different from > the one given to the client. Yes. That is what is meant. > > - Chapter 5, 1st paragraph, last sentence seems to be missing text in > the beginning which is a little confusing. Stray text from lots of cut/paste. I removed it. > > - Ch. 5.1, 4th paragraph, 1st sentence "identifies a documents". Fixed. > ^^ > > - Ch 5.2 begins with "The second component". Isn't it rather the third > component after the services root URI and AUID+users/global subtree? I see why this is confusing. The document talks about root services URI, but it also says that the overall URI is divided into the Document URI and the node selector. The "2nd component" is referring to the "node selector" in the latter breakdown. I clarified the wording. > > - Ch 5.2, grammar: The document should give references to the XML > specifications. Currently only XPath and XML Schema seem to be there. I know. I didnt get around to filling in the references. > > - Ch 5.2, 3rd paragraph (not counting grammar), s/To determne/To determine/ Fixed. > > - Ch 6.5, last paragraph, 2nd s., "...is up the local file..." > ^ to > Fixed. > - Ch 7.2, 4th paragraph, 4th s., "...matches an ent within..." I guess > should be "an existing attribute"? Yup, fixed. More copy/paste errors. > > - Ch 7.5, There was already a comment about etags usage on the list, so > just to resonate that, it isn't immediately clear what the benefits are > for having each attribute in an element have an etag that is independent > of that element's etag. Yes, I have posted on this separately. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:56:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17134 for ; Thu, 13 Nov 2003 03:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGu-0002tW-NZ for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:56:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8uCXJ011120 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGu-0002tH-FO for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17108; Thu, 13 Nov 2003 03:56:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDGq-00016r-00; Thu, 13 Nov 2003 03:56:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDGq-00016o-00; Thu, 13 Nov 2003 03:56:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDGk-0002rx-Nd; Thu, 13 Nov 2003 03:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDG9-0002pY-KF for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17044 for ; Thu, 13 Nov 2003 03:55:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDG6-00015T-00 for simple@ietf.org; Thu, 13 Nov 2003 03:55:22 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDG6-00014k-00 for simple@ietf.org; Thu, 13 Nov 2003 03:55:22 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8stca016572; Thu, 13 Nov 2003 03:54:55 -0500 (EST) Message-ID: <3FB346DC.8060009@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: simple@ietf.org Subject: Re: [Simple] XCAP comments References: <3FAFC585.4050107@nokia.com> In-Reply-To: <3FAFC585.4050107@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:54:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Aki Niemi wrote: > Hi, > > Overall, I like XCAP - it's elegant and well written. Thanks! > My comments are > nothing major, but mostly nits and such. > > Cheers, > Aki > > --- > > - Chapter 4, paragraph beginning with "Resource Interdependencies", last > sentence says: > > Concretely, > this means that, after the server modifies the data, the entity > tags are updated as if the client had made the change itself. > > Does this mean that if the server changes something as a result of the > XCAP operation, the change will show as one made by the client? No. This text is not clear at all (I think Hisham commented on it too). It means that, the server effectively acts like *another* client. So, if the actual client tried to do a PUT with If-Match on the Etag, it would fail. It needs to fetch the doc to get the update. > Is that > the right way to do it, because in effect this would not require the > client to fetch this data, as it would seem like something already > up-to-date? The client is required to fetch it, but the etags will make it clear that the client does not have an up to date copy. > > I think the proper thing to do would be to make the etag different from > the one given to the client. Yes. That is what is meant. > > - Chapter 5, 1st paragraph, last sentence seems to be missing text in > the beginning which is a little confusing. Stray text from lots of cut/paste. I removed it. > > - Ch. 5.1, 4th paragraph, 1st sentence "identifies a documents". Fixed. > ^^ > > - Ch 5.2 begins with "The second component". Isn't it rather the third > component after the services root URI and AUID+users/global subtree? I see why this is confusing. The document talks about root services URI, but it also says that the overall URI is divided into the Document URI and the node selector. The "2nd component" is referring to the "node selector" in the latter breakdown. I clarified the wording. > > - Ch 5.2, grammar: The document should give references to the XML > specifications. Currently only XPath and XML Schema seem to be there. I know. I didnt get around to filling in the references. > > - Ch 5.2, 3rd paragraph (not counting grammar), s/To determne/To determine/ Fixed. > > - Ch 6.5, last paragraph, 2nd s., "...is up the local file..." > ^ to > Fixed. > - Ch 7.2, 4th paragraph, 4th s., "...matches an ent within..." I guess > should be "an existing attribute"? Yup, fixed. More copy/paste errors. > > - Ch 7.5, There was already a comment about etags usage on the list, so > just to resonate that, it isn't immediately clear what the benefits are > for having each attribute in an element have an etag that is independent > of that element's etag. Yes, I have posted on this separately. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 03:58:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17209; Thu, 13 Nov 2003 03:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDJe-000192-00; Thu, 13 Nov 2003 03:59:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDJd-00018z-00; Thu, 13 Nov 2003 03:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDJd-000376-0l; Thu, 13 Nov 2003 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDIv-000366-NK for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17201 for ; Thu, 13 Nov 2003 03:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDIt-00018Y-00 for simple@ietf.org; Thu, 13 Nov 2003 03:58:15 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDIs-00018K-00 for simple@ietf.org; Thu, 13 Nov 2003 03:58:14 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8vlca016575; Thu, 13 Nov 2003 03:57:48 -0500 (EST) Message-ID: <3FB34788.6040207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org Subject: Re: [Simple] comments on draft-isomaki-simple-xcap-publish-usage References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:57:44 -0500 Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi, > > Thanks for the comments. See below: > > >> -----Original Message----- From: simple-admin@ietf.org >> [mailto:simple-admin@ietf.org]On Behalf Of ext Jonathan Rosenberg >> Sent: 10 November, 2003 18:06 To: Simple WG Subject: [Simple] >> comments on draft-isomaki-simple-xcap-publish-usage >> >> >> I have a few comments on: >> >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap- >> publish-usage-00.txt >> >> I think this is a good draft, and is the appropriate way to solve >> this problem. >> >> My main comment is that I think we need to be very clear on the >> difference between this mechanism and SIP PUBLISH. I know we went >> through a lot of this on the list some time back. In particular, >> one could presumably use PUBLISH with an infinitely long Expires >> header field, and achieve a near "hard state" publication. I >> think the real difference is that this is provisioned data that >> describes the presentity independent of any particular device, >> for which we require any possible device, and even web pages and >> provisioning systems, to manipulate. PUBLISH is really focused on >> allowing a particular PUA to publish its view of the presentity, >> separate from other views published by other PUAs. As such, >> manipulating presence hard state from many different sources >> using PUBLISH is not easy, as the Etags would need to be shared. >> There is no obvious mechanism for that. Also, there will be a >> clear need to do a pure fetch of the hard state presence data, a >> feature we don't have with PUBLISH. I think the draft should >> clearly enumerate these problems, and provide guidance on when to >> use this mechanism, vs. PUBLISH. >> > > > I think this is a good description on the benefits of XCAP presence > publishing application usage compared to SIP PUBLISH. Aki also > provided some consideration why SIP PUBLISH with infinite > expiration might not work. I agree that all this should be added to > the next revision of the draft. Right. I agree with Aki's discussion on the infinite expiration doesnt work. My main point is that the text needs to discuss these things, NOT that I was proposing PUBLISH! > > >> Regarding the open issue: >> >> >>> Publishing of external content: how to publish external content >>> (e.g., an icon) referenced from PIDF in case of the XCAP based >>> publishing? Is the content transported separately from the >>> PIDF formatted document so that the PIDF includes only a >> >> reference to the >> >>> separately transported content and the compositor is capable >>> for linking the information together? This might require that >>> the compositor is able to change the content of the reference. >> >> This is more of a pidf question, I think. The current leaning >> with PIDF would be to include such icons by reference. The >> document stored in the xcap server would include such a >> reference. That reference would presumably be an HTTP URI that >> can dreference content on the same server. The user would need to >> have a directory where they are permitted to upload content. >> > > > I agree that the best way would be to upload the external content > separately using HTTP PUT and insert the URI to PIDF. In some cases > the PA might want to send such information also within the NOTIFY, > in which case the PA would need to fetch the data addressed by the > HTTP URI, insert it as a separate MIME part and replace the HTTP > URI in PIDF by a corresponding cid URI. > > Can this kind of behaviour be seen purely as an implementation > issue, or is there need to write something about it somewhere? I think if you want NOTIFY's to contain PIDF documents with references to CID URIs in the same NOTIFY, you need to write that up. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 03:59:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17237 for ; Thu, 13 Nov 2003 03:59:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDJk-0003CD-Ha for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD8x8L2012149 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 03:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDJh-00039s-Qd for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 03:59:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17209; Thu, 13 Nov 2003 03:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDJe-000192-00; Thu, 13 Nov 2003 03:59:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDJd-00018z-00; Thu, 13 Nov 2003 03:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDJd-000376-0l; Thu, 13 Nov 2003 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDIv-000366-NK for simple@optimus.ietf.org; Thu, 13 Nov 2003 03:58:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17201 for ; Thu, 13 Nov 2003 03:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDIt-00018Y-00 for simple@ietf.org; Thu, 13 Nov 2003 03:58:15 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDIs-00018K-00 for simple@ietf.org; Thu, 13 Nov 2003 03:58:14 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD8vlca016575; Thu, 13 Nov 2003 03:57:48 -0500 (EST) Message-ID: <3FB34788.6040207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org Subject: Re: [Simple] comments on draft-isomaki-simple-xcap-publish-usage References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 03:57:44 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi, > > Thanks for the comments. See below: > > >> -----Original Message----- From: simple-admin@ietf.org >> [mailto:simple-admin@ietf.org]On Behalf Of ext Jonathan Rosenberg >> Sent: 10 November, 2003 18:06 To: Simple WG Subject: [Simple] >> comments on draft-isomaki-simple-xcap-publish-usage >> >> >> I have a few comments on: >> >> http://www.ietf.org/internet-drafts/draft-isomaki-simple-xcap- >> publish-usage-00.txt >> >> I think this is a good draft, and is the appropriate way to solve >> this problem. >> >> My main comment is that I think we need to be very clear on the >> difference between this mechanism and SIP PUBLISH. I know we went >> through a lot of this on the list some time back. In particular, >> one could presumably use PUBLISH with an infinitely long Expires >> header field, and achieve a near "hard state" publication. I >> think the real difference is that this is provisioned data that >> describes the presentity independent of any particular device, >> for which we require any possible device, and even web pages and >> provisioning systems, to manipulate. PUBLISH is really focused on >> allowing a particular PUA to publish its view of the presentity, >> separate from other views published by other PUAs. As such, >> manipulating presence hard state from many different sources >> using PUBLISH is not easy, as the Etags would need to be shared. >> There is no obvious mechanism for that. Also, there will be a >> clear need to do a pure fetch of the hard state presence data, a >> feature we don't have with PUBLISH. I think the draft should >> clearly enumerate these problems, and provide guidance on when to >> use this mechanism, vs. PUBLISH. >> > > > I think this is a good description on the benefits of XCAP presence > publishing application usage compared to SIP PUBLISH. Aki also > provided some consideration why SIP PUBLISH with infinite > expiration might not work. I agree that all this should be added to > the next revision of the draft. Right. I agree with Aki's discussion on the infinite expiration doesnt work. My main point is that the text needs to discuss these things, NOT that I was proposing PUBLISH! > > >> Regarding the open issue: >> >> >>> Publishing of external content: how to publish external content >>> (e.g., an icon) referenced from PIDF in case of the XCAP based >>> publishing? Is the content transported separately from the >>> PIDF formatted document so that the PIDF includes only a >> >> reference to the >> >>> separately transported content and the compositor is capable >>> for linking the information together? This might require that >>> the compositor is able to change the content of the reference. >> >> This is more of a pidf question, I think. The current leaning >> with PIDF would be to include such icons by reference. The >> document stored in the xcap server would include such a >> reference. That reference would presumably be an HTTP URI that >> can dreference content on the same server. The user would need to >> have a directory where they are permitted to upload content. >> > > > I agree that the best way would be to upload the external content > separately using HTTP PUT and insert the URI to PIDF. In some cases > the PA might want to send such information also within the NOTIFY, > in which case the PA would need to fetch the data addressed by the > HTTP URI, insert it as a separate MIME part and replace the HTTP > URI in PIDF by a corresponding cid URI. > > Can this kind of behaviour be seen purely as an implementation > issue, or is there need to write something about it somewhere? I think if you want NOTIFY's to contain PIDF documents with references to CID URIs in the same NOTIFY, you need to write that up. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 04:15:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17797; Thu, 13 Nov 2003 04:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDZJ-0001N5-00; Thu, 13 Nov 2003 04:15:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDZJ-0001N2-00; Thu, 13 Nov 2003 04:15:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDZ9-0004XY-5R; Thu, 13 Nov 2003 04:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDYs-0004X4-Hb for simple@optimus.ietf.org; Thu, 13 Nov 2003 04:14:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17789 for ; Thu, 13 Nov 2003 04:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDYp-0001Mq-00 for simple@ietf.org; Thu, 13 Nov 2003 04:14:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDYp-0001MQ-00 for simple@ietf.org; Thu, 13 Nov 2003 04:14:43 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD9EGca016582; Thu, 13 Nov 2003 04:14:16 -0500 (EST) Message-ID: <3FB34B65.5060109@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-list-usage References: <2038BCC78B1AD641891A0D1AE133DBB701797378@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797378@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 04:14:13 -0500 Content-Transfer-Encoding: 7bit Hisham, Thanks for your comments. Responses inline. hisham.khartabil@nokia.com wrote: > - Subscribeable: by whom? Who is authorised to subscribe to this > list, besides the creator of the list? How that indicated? Good question. There is nothing in this application usage that defines authorization policies for list subscriptions. I think we should add text to the xcap-list spec that says that. In such a case, the provider's authorization policies would apply. I expect in many cases these policies only allow the owner of the list to subscribe to it. I also think it makes sense as a follow on activity to write an xcap usage for authorization policies for list subscriptions. > > - If the "uri" attribute is absent in a document, but the > "subscribeable" flag is set to true. the XCAP server must allocate > a URI. But what if the URI is present but conflicts with an already > existing URI? How does the server react? Does it reject the request > or does it just rewrite the URI? Great question. I think it should return an error. The reason is that the document would be in violation of one of the non-schema data constraints. The real question is, how does the client know that it should retry with a different URI? I see no obvious answer. There are a few possibilities: * disallow clients from setting the URI * invent a new error resposne code * add a body to the 409 that describes the condition > > - Why does the URI need to be globally unique? Can it be unique per > user (i.e. a user can't create 2 lists with the same URI)? we all > have friends@company.com. I guess the answer to this depends on the > answer to the first question: If only the creator can subscribe to > the list, then the URIs can be unique to that user only. The server > asserts the user and then know that he is subscribing to his > friends@company.com. This would not work if multiple users can > subscribe to my list. Which I think we ultimately want. I think its a risky venture to make the actual resource definition depend on both the URI *and* the user that is asking. The fact that the URI may be ugly has no relevance to how its rendered to users. Its perfectly fine if all they ever see is "Friends". Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 04:15:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17814 for ; Thu, 13 Nov 2003 04:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDZO-0004bn-Db for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 04:15:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD9FH9n017713 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 04:15:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDZN-0004bY-CY for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 04:15:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17797; Thu, 13 Nov 2003 04:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDZJ-0001N5-00; Thu, 13 Nov 2003 04:15:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDZJ-0001N2-00; Thu, 13 Nov 2003 04:15:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDZ9-0004XY-5R; Thu, 13 Nov 2003 04:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDYs-0004X4-Hb for simple@optimus.ietf.org; Thu, 13 Nov 2003 04:14:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17789 for ; Thu, 13 Nov 2003 04:14:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDYp-0001Mq-00 for simple@ietf.org; Thu, 13 Nov 2003 04:14:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDYp-0001MQ-00 for simple@ietf.org; Thu, 13 Nov 2003 04:14:43 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD9EGca016582; Thu, 13 Nov 2003 04:14:16 -0500 (EST) Message-ID: <3FB34B65.5060109@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Comments on xcap-list-usage References: <2038BCC78B1AD641891A0D1AE133DBB701797378@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797378@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 04:14:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hisham, Thanks for your comments. Responses inline. hisham.khartabil@nokia.com wrote: > - Subscribeable: by whom? Who is authorised to subscribe to this > list, besides the creator of the list? How that indicated? Good question. There is nothing in this application usage that defines authorization policies for list subscriptions. I think we should add text to the xcap-list spec that says that. In such a case, the provider's authorization policies would apply. I expect in many cases these policies only allow the owner of the list to subscribe to it. I also think it makes sense as a follow on activity to write an xcap usage for authorization policies for list subscriptions. > > - If the "uri" attribute is absent in a document, but the > "subscribeable" flag is set to true. the XCAP server must allocate > a URI. But what if the URI is present but conflicts with an already > existing URI? How does the server react? Does it reject the request > or does it just rewrite the URI? Great question. I think it should return an error. The reason is that the document would be in violation of one of the non-schema data constraints. The real question is, how does the client know that it should retry with a different URI? I see no obvious answer. There are a few possibilities: * disallow clients from setting the URI * invent a new error resposne code * add a body to the 409 that describes the condition > > - Why does the URI need to be globally unique? Can it be unique per > user (i.e. a user can't create 2 lists with the same URI)? we all > have friends@company.com. I guess the answer to this depends on the > answer to the first question: If only the creator can subscribe to > the list, then the URIs can be unique to that user only. The server > asserts the user and then know that he is subscribing to his > friends@company.com. This would not work if multiple users can > subscribe to my list. Which I think we ultimately want. I think its a risky venture to make the actual resource definition depend on both the URI *and* the user that is asking. The fact that the URI may be ugly has no relevance to how its rendered to users. Its perfectly fine if all they ever see is "Friends". Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 04:34:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18085; Thu, 13 Nov 2003 04:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDrn-0001ZK-00; Thu, 13 Nov 2003 04:34:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDrm-0001ZH-00; Thu, 13 Nov 2003 04:34:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDrV-0005Ks-Vw; Thu, 13 Nov 2003 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDr9-0005Hz-F8 for simple@optimus.ietf.org; Thu, 13 Nov 2003 04:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18065 for ; Thu, 13 Nov 2003 04:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDr6-0001Yf-00 for simple@ietf.org; Thu, 13 Nov 2003 04:33:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDr5-0001YQ-00 for simple@ietf.org; Thu, 13 Nov 2003 04:33:35 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD9X7ca016601; Thu, 13 Nov 2003 04:33:08 -0500 (EST) Message-ID: <3FB34FD0.8080209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: naoko@netlab.nec.co.jp, simple@ietf.org Subject: Re: [Simple] Questions on XCAP Usage for Authorization References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 04:33:04 -0500 Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi, > > Jonathan Rosenberg replies to Naoko Ito: > >>>- Is there any way to reject a watcher who is given permissions by >>> other statements? >>> ex) Give a permission to any user whose domain is >> >>"example.com" but >> >>> Joe. >> >>Yes, now that is possible in -01. You would define a statement that >>allows anyone but Joe: >> >> >> >> example.com >> >> sip:joe@example.com >> >> >> >> >> >> >>and to reject Joe, there would be this statement: >> >> >> >> sip:joe@example.com >> >> >> >>Note how, in the second statement, there is an applies-to, but *no* >>permissions. I.e., the way to reject someone is that they are granted >>no permissions. > > > If the default is that no-one is granted no permissions, what is the difference the second statement makes? The difference is whether or not reactive authorization needs to be used. In the current draft, lack of any statements that apply to a watcher means that they are pending, and so winfo would indicate to the presentity that a permission needs to be applied. If I want to deny them, I would go and add the above statement. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 04:34:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18109 for ; Thu, 13 Nov 2003 04:34:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDrs-0005NI-70 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 04:34:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD9YOQm020659 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 04:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDrr-0005N7-Bg for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 04:34:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18085; Thu, 13 Nov 2003 04:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDrn-0001ZK-00; Thu, 13 Nov 2003 04:34:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKDrm-0001ZH-00; Thu, 13 Nov 2003 04:34:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDrV-0005Ks-Vw; Thu, 13 Nov 2003 04:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKDr9-0005Hz-F8 for simple@optimus.ietf.org; Thu, 13 Nov 2003 04:33:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18065 for ; Thu, 13 Nov 2003 04:33:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKDr6-0001Yf-00 for simple@ietf.org; Thu, 13 Nov 2003 04:33:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKDr5-0001YQ-00 for simple@ietf.org; Thu, 13 Nov 2003 04:33:35 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD9X7ca016601; Thu, 13 Nov 2003 04:33:08 -0500 (EST) Message-ID: <3FB34FD0.8080209@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: naoko@netlab.nec.co.jp, simple@ietf.org Subject: Re: [Simple] Questions on XCAP Usage for Authorization References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 04:33:04 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Markus.Isomaki@nokia.com wrote: > Hi, > > Jonathan Rosenberg replies to Naoko Ito: > >>>- Is there any way to reject a watcher who is given permissions by >>> other statements? >>> ex) Give a permission to any user whose domain is >> >>"example.com" but >> >>> Joe. >> >>Yes, now that is possible in -01. You would define a statement that >>allows anyone but Joe: >> >> >> >> example.com >> >> sip:joe@example.com >> >> >> >> >> >> >>and to reject Joe, there would be this statement: >> >> >> >> sip:joe@example.com >> >> >> >>Note how, in the second statement, there is an applies-to, but *no* >>permissions. I.e., the way to reject someone is that they are granted >>no permissions. > > > If the default is that no-one is granted no permissions, what is the difference the second statement makes? The difference is whether or not reactive authorization needs to be used. In the current draft, lack of any statements that apply to a watcher means that they are pending, and so winfo would indicate to the presentity that a permission needs to be applied. If I want to deny them, I would go and add the above statement. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 05:31:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19778; Thu, 13 Nov 2003 05:31:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKElk-0002QH-00; Thu, 13 Nov 2003 05:32:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKElk-0002QE-00; Thu, 13 Nov 2003 05:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKEle-0008OO-47; Thu, 13 Nov 2003 05:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKElU-0008O7-NT for simple@optimus.ietf.org; Thu, 13 Nov 2003 05:31:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19750 for ; Thu, 13 Nov 2003 05:31:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKElR-0002PT-00 for simple@ietf.org; Thu, 13 Nov 2003 05:31:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKElQ-0002PI-00 for simple@ietf.org; Thu, 13 Nov 2003 05:31:48 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hADAVMca016638 for ; Thu, 13 Nov 2003 05:31:22 -0500 (EST) Message-ID: <3FB35D77.1090508@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] comments on winfo-history Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 05:31:19 -0500 Content-Transfer-Encoding: 7bit A comment on: http://www.ietf.org/internet-drafts/draft-niemi-simple-winfo-history-00.txt My apologies for not reading this and commenting sooner. The problem described in this draft is the exact reason why the waiting state exists in the current winfo specifications. If a user is pending, and then their susbcription expires, the information goes into the waiting state, where it remains for a long time. The purpose of that is for a user to find out who attempted to subscribe when they were offline. Quoting from the winfo package: > The waiting state is similar to pending, in that no notifications are > generated. However, if the subscription is approved or denied, the > FSM is destroyed. The purpose of the waiting state is so that a user > can fetch watcherinfo state at any time, and learn of any > subscriptions that arrived previously (and which may arrive again) > which require an authorization decision. Consider an example. A > subscribes to B. B has not defined policy about this subscription, so > it moves into the pending state. B is not "online", so that B's > software agent cannot be contacted to approve the subscription. The > subscription expires. Let's say it were destroyed. B logs in, and > fetches its watcherinfo state. There is no record of the subscription > from A, so no policy decision is made about subscriptions from A. B > logs off. A refreshes its subscription. Once more, the subscription > is pending since no policy is defined for it. This process could > continue indefinitely. The waiting state ensures that B can find out > about this subscription attempt. I believe this meets your needs as specified. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 05:32:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19798 for ; Thu, 13 Nov 2003 05:32:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKElp-0008QG-NV for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 05:32:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADAWDNr032375 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 05:32:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKElp-0008Q6-2K for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 05:32:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19778; Thu, 13 Nov 2003 05:31:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKElk-0002QH-00; Thu, 13 Nov 2003 05:32:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKElk-0002QE-00; Thu, 13 Nov 2003 05:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKEle-0008OO-47; Thu, 13 Nov 2003 05:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKElU-0008O7-NT for simple@optimus.ietf.org; Thu, 13 Nov 2003 05:31:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19750 for ; Thu, 13 Nov 2003 05:31:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKElR-0002PT-00 for simple@ietf.org; Thu, 13 Nov 2003 05:31:49 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKElQ-0002PI-00 for simple@ietf.org; Thu, 13 Nov 2003 05:31:48 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hADAVMca016638 for ; Thu, 13 Nov 2003 05:31:22 -0500 (EST) Message-ID: <3FB35D77.1090508@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] comments on winfo-history Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 05:31:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A comment on: http://www.ietf.org/internet-drafts/draft-niemi-simple-winfo-history-00.txt My apologies for not reading this and commenting sooner. The problem described in this draft is the exact reason why the waiting state exists in the current winfo specifications. If a user is pending, and then their susbcription expires, the information goes into the waiting state, where it remains for a long time. The purpose of that is for a user to find out who attempted to subscribe when they were offline. Quoting from the winfo package: > The waiting state is similar to pending, in that no notifications are > generated. However, if the subscription is approved or denied, the > FSM is destroyed. The purpose of the waiting state is so that a user > can fetch watcherinfo state at any time, and learn of any > subscriptions that arrived previously (and which may arrive again) > which require an authorization decision. Consider an example. A > subscribes to B. B has not defined policy about this subscription, so > it moves into the pending state. B is not "online", so that B's > software agent cannot be contacted to approve the subscription. The > subscription expires. Let's say it were destroyed. B logs in, and > fetches its watcherinfo state. There is no record of the subscription > from A, so no policy decision is made about subscriptions from A. B > logs off. A refreshes its subscription. Once more, the subscription > is pending since no policy is defined for it. This process could > continue indefinitely. The waiting state ensures that B can find out > about this subscription attempt. I believe this meets your needs as specified. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 09:45:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29032; Thu, 13 Nov 2003 09:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIjT-00061D-00; Thu, 13 Nov 2003 09:46:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKIjT-00061A-00; Thu, 13 Nov 2003 09:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIjS-00065p-6R; Thu, 13 Nov 2003 09:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIiT-0005yK-TG for simple@optimus.ietf.org; Thu, 13 Nov 2003 09:45:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28964 for ; Thu, 13 Nov 2003 09:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIiR-0005xi-00 for simple@ietf.org; Thu, 13 Nov 2003 09:44:59 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKIiR-0005x5-00 for simple@ietf.org; Thu, 13 Nov 2003 09:44:59 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADEiOAt010555; Thu, 13 Nov 2003 06:44:25 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-42.cisco.com [10.86.240.42]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADY57337; Thu, 13 Nov 2003 09:44:23 -0500 (EST) Message-ID: <3FB398C6.7060900@cisco.com> 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: Adam Roach CC: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 09:44:22 -0500 Content-Transfer-Encoding: 7bit Adam Roach wrote: > I would argue that, as with every other request you send, > the application behavior depends on the request URI. Well, if it has been agreed that you first choose a server and then send it a list, I agree this seems like a plausible approach. But in that case, unless there is an agreement on how to standardize servers (by name or whatever), there isn't really much need to standardize *anything* about this behavior - even the name of the parameter (list=). It perhaps just becomes some sort of best practices or informational draft. I'm still thinking about whether I like this or not. Paul > So, for example, I could deploy an application server in > the middle of the network that treats: > > INVITE sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com > SIP/2.0 > > ...very differently than... > > INVITE sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > /a > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, November 12, 2003 12:39 >>To: Markus.Isomaki@nokia.com >>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >>There seems to be an assumption here that sending an INVITE >>to an ad hoc >>list should create a conference. That is certainly one >>interpretation, >>but not the only possible one. If the ad hoc list server is a simple >>message exploder then you probably aren't going to get a conference. >> >>If you have a list of people and want to set up a conference >>there are >>other ways to do it, so trying to bend ad hoc list to do this >>may not be >>justified. >> >> Paul >> >>Markus.Isomaki@nokia.com wrote: >> >>>Hi, >>> >>>I believe the best way would be for them to subscribe to >> >>conference-state event package, if that is available. But I >>guess there is a bigger issue here: What is the relationship >>between a conference started through an exploder and a >>conference setup for with CPCP a la XCON. Is it possible to >>migrate from an exploder conference to CPCP-controllable one >>(given that the server supports CPCP, conference notification >>service etc.)? >> >>>I have yet another requirement for this ad hoc list / >> >>exploder solution. Especially in the case of MESSAGE to a >>list, it would be nice to be able to convey to the recipients >>the list of other recipients. It should be possible for the >>original sender to indicate this. It shouldn't be too hard to >>map the headers/payload from incoming to outgoing side for >>this purpose within the "exploder server". >> >>>Markus >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >>> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Dean Willis >>>>Sent: 12 November, 2003 16:56 >>>>To: Jonathan Rosenberg >>>>Cc: Simple WG >>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>> >>>> >>>> >>>> >>>> >>>>>I dont get this. I thought that an ad-hoc list would be >>>> >>>>scoped to the >>>> >>>> >>>>>subscription, in which case, there wouldnt be any other >>>> >>>>subscribers. Am >>>> >>>> >>>>>I missing something? >>>> >>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>>>conference. Would "members" of the list (i.e., participants in the >>>>conference) subscribe to the list, or to the conference in order to >>>>learn about changes to the participant set? >>>> >>>>-- >>>>Dean >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 09:46:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29084 for ; Thu, 13 Nov 2003 09:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIjW-00066w-Uy for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 09:46:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADEk6L7023483 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 09:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIjW-00066g-Pr for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 09:46:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29032; Thu, 13 Nov 2003 09:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIjT-00061D-00; Thu, 13 Nov 2003 09:46:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKIjT-00061A-00; Thu, 13 Nov 2003 09:46:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIjS-00065p-6R; Thu, 13 Nov 2003 09:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKIiT-0005yK-TG for simple@optimus.ietf.org; Thu, 13 Nov 2003 09:45:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28964 for ; Thu, 13 Nov 2003 09:44:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKIiR-0005xi-00 for simple@ietf.org; Thu, 13 Nov 2003 09:44:59 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKIiR-0005x5-00 for simple@ietf.org; Thu, 13 Nov 2003 09:44:59 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADEiOAt010555; Thu, 13 Nov 2003 06:44:25 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-42.cisco.com [10.86.240.42]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADY57337; Thu, 13 Nov 2003 09:44:23 -0500 (EST) Message-ID: <3FB398C6.7060900@cisco.com> 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: Adam Roach CC: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FC@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 09:44:22 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > I would argue that, as with every other request you send, > the application behavior depends on the request URI. Well, if it has been agreed that you first choose a server and then send it a list, I agree this seems like a plausible approach. But in that case, unless there is an agreement on how to standardize servers (by name or whatever), there isn't really much need to standardize *anything* about this behavior - even the name of the parameter (list=). It perhaps just becomes some sort of best practices or informational draft. I'm still thinking about whether I like this or not. Paul > So, for example, I could deploy an application server in > the middle of the network that treats: > > INVITE sip:conference@example.com;list=cid:cn35t8jf02@terminal.foo.com > SIP/2.0 > > ...very differently than... > > INVITE sip:fork@example.com;list=cid:cn35t8jf02@terminal.foo.com SIP/2.0 > > /a > > >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: Wednesday, November 12, 2003 12:39 >>To: Markus.Isomaki@nokia.com >>Cc: dean.willis@softarmor.com; jdrosen@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] ad-hoc list subscriptions >> >> >>There seems to be an assumption here that sending an INVITE >>to an ad hoc >>list should create a conference. That is certainly one >>interpretation, >>but not the only possible one. If the ad hoc list server is a simple >>message exploder then you probably aren't going to get a conference. >> >>If you have a list of people and want to set up a conference >>there are >>other ways to do it, so trying to bend ad hoc list to do this >>may not be >>justified. >> >> Paul >> >>Markus.Isomaki@nokia.com wrote: >> >>>Hi, >>> >>>I believe the best way would be for them to subscribe to >> >>conference-state event package, if that is available. But I >>guess there is a bigger issue here: What is the relationship >>between a conference started through an exploder and a >>conference setup for with CPCP a la XCON. Is it possible to >>migrate from an exploder conference to CPCP-controllable one >>(given that the server supports CPCP, conference notification >>service etc.)? >> >>>I have yet another requirement for this ad hoc list / >> >>exploder solution. Especially in the case of MESSAGE to a >>list, it would be nice to be able to convey to the recipients >>the list of other recipients. It should be possible for the >>original sender to indicate this. It shouldn't be too hard to >>map the headers/payload from incoming to outgoing side for >>this purpose within the "exploder server". >> >>>Markus >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >>> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Dean Willis >>>>Sent: 12 November, 2003 16:56 >>>>To: Jonathan Rosenberg >>>>Cc: Simple WG >>>>Subject: Re: [Simple] ad-hoc list subscriptions >>>> >>>> >>>> >>>> >>>> >>>>>I dont get this. I thought that an ad-hoc list would be >>>> >>>>scoped to the >>>> >>>> >>>>>subscription, in which case, there wouldnt be any other >>>> >>>>subscribers. Am >>>> >>>> >>>>>I missing something? >>>> >>>>Ok, assume I send an INVITE to an ad-hoc list, forming an ad-hoc >>>>conference. Would "members" of the list (i.e., participants in the >>>>conference) subscribe to the list, or to the conference in order to >>>>learn about changes to the participant set? >>>> >>>>-- >>>>Dean >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 10:28:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02837; Thu, 13 Nov 2003 10:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJP7-0006sT-00; Thu, 13 Nov 2003 10:29:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJP6-0006sQ-00; Thu, 13 Nov 2003 10:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJP4-0003b3-63; Thu, 13 Nov 2003 10:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJOQ-0003aG-PI for simple@optimus.ietf.org; Thu, 13 Nov 2003 10:28:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02809 for ; Thu, 13 Nov 2003 10:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJOO-0006s1-00 for simple@ietf.org; Thu, 13 Nov 2003 10:28:20 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKJON-0006rt-00 for simple@ietf.org; Thu, 13 Nov 2003 10:28:19 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hADFQiGd025787; Thu, 13 Nov 2003 09:26:45 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 09:26:45 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86605@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 09:26:44 -0600 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > [U]nless there is an agreement on how to standardize > servers (by name or whatever), there isn't really much need to > standardize *anything* about this behavior - even the name of the > parameter (list=). It perhaps just becomes some sort of best > practices or informational draft. I came to the same conclusion. I think I like that fact. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 10:29:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02883 for ; Thu, 13 Nov 2003 10:29:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJPB-0003dY-5h for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 10:29:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFT97U013974 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 10:29:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJPA-0003dJ-TN for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 10:29:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02837; Thu, 13 Nov 2003 10:28:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJP7-0006sT-00; Thu, 13 Nov 2003 10:29:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJP6-0006sQ-00; Thu, 13 Nov 2003 10:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJP4-0003b3-63; Thu, 13 Nov 2003 10:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJOQ-0003aG-PI for simple@optimus.ietf.org; Thu, 13 Nov 2003 10:28:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02809 for ; Thu, 13 Nov 2003 10:28:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJOO-0006s1-00 for simple@ietf.org; Thu, 13 Nov 2003 10:28:20 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKJON-0006rt-00 for simple@ietf.org; Thu, 13 Nov 2003 10:28:19 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hADFQiGd025787; Thu, 13 Nov 2003 09:26:45 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 09:26:45 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86605@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Paul Kyzivat'" , Adam Roach Cc: Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 09:26:44 -0600 Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > [U]nless there is an agreement on how to standardize > servers (by name or whatever), there isn't really much need to > standardize *anything* about this behavior - even the name of the > parameter (list=). It perhaps just becomes some sort of best > practices or informational draft. I came to the same conclusion. I think I like that fact. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 11:05:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04965; Thu, 13 Nov 2003 11:05:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJy2-0007eI-00; Thu, 13 Nov 2003 11:05:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJy2-0007eF-00; Thu, 13 Nov 2003 11:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxu-000759-Vt; Thu, 13 Nov 2003 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxP-000744-7A for simple@optimus.ietf.org; Thu, 13 Nov 2003 11:04:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04939 for ; Thu, 13 Nov 2003 11:04:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJxM-0007dC-00 for simple@ietf.org; Thu, 13 Nov 2003 11:04:28 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AKJxL-0007d9-00 for simple@ietf.org; Thu, 13 Nov 2003 11:04:27 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hADG4Q305661; Thu, 13 Nov 2003 11:04:26 -0500 To: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Managing XCAP Etags References: <3FA75F19.8080802@nokia.com> <3FB33FC7.3060506@dynamicsoft.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: <3FB33FC7.3060506@dynamicsoft.com> (Jonathan Rosenberg's message of "Thu, 13 Nov 2003 03:24:39 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 11:04:26 -0500 Jonathan Rosenberg writes: > I think that, when there is a modification to a component of the document, > the server would assign the same Etag to all of the ancestor and descendant > components. This way, if the client is the only one ever manipulating the > document, it knows what the various etags are without having to query them. HTTP says that the Etag is associated with the Request URL - all of the URL. However, it also says that the Etag value is created by the server using any algorithm it chooses; clients don't get to interpret Etags, just accept them and pass them back as qualifiers in conditional requests. I don't think that xcap needs to specify anything about the server policy for etag generation - the server returns an etag, the client echos it to qualify its update request. Whether the server associated the Etag with the entire document (as it should if it can't manage non-overlaping changes within the same document), or whether it assigned the value in such a way that allows it to do a partial update is not important to the client, and need not be in the spec. -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 11:05:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04994 for ; Thu, 13 Nov 2003 11:05:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJy6-0007BA-RC for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 11:05:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADG5E9F027595 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 11:05:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJy6-0007B0-N9 for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 11:05:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04965; Thu, 13 Nov 2003 11:05:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJy2-0007eI-00; Thu, 13 Nov 2003 11:05:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKJy2-0007eF-00; Thu, 13 Nov 2003 11:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxu-000759-Vt; Thu, 13 Nov 2003 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJxP-000744-7A for simple@optimus.ietf.org; Thu, 13 Nov 2003 11:04:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04939 for ; Thu, 13 Nov 2003 11:04:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJxM-0007dC-00 for simple@ietf.org; Thu, 13 Nov 2003 11:04:28 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AKJxL-0007d9-00 for simple@ietf.org; Thu, 13 Nov 2003 11:04:27 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hADG4Q305661; Thu, 13 Nov 2003 11:04:26 -0500 To: Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] Managing XCAP Etags References: <3FA75F19.8080802@nokia.com> <3FB33FC7.3060506@dynamicsoft.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: <3FB33FC7.3060506@dynamicsoft.com> (Jonathan Rosenberg's message of "Thu, 13 Nov 2003 03:24:39 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 11:04:26 -0500 Jonathan Rosenberg writes: > I think that, when there is a modification to a component of the document, > the server would assign the same Etag to all of the ancestor and descendant > components. This way, if the client is the only one ever manipulating the > document, it knows what the various etags are without having to query them. HTTP says that the Etag is associated with the Request URL - all of the URL. However, it also says that the Etag value is created by the server using any algorithm it chooses; clients don't get to interpret Etags, just accept them and pass them back as qualifiers in conditional requests. I don't think that xcap needs to specify anything about the server policy for etag generation - the server returns an etag, the client echos it to qualify its update request. Whether the server associated the Etag with the entire document (as it should if it can't manage non-overlaping changes within the same document), or whether it assigned the value in such a way that allows it to do a partial update is not important to the client, and need not be in the spec. -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 12:36:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09900; Thu, 13 Nov 2003 12:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLP0-0001fG-00; Thu, 13 Nov 2003 12:37:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKLOz-0001fD-00; Thu, 13 Nov 2003 12:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLOv-0007J8-Bi; Thu, 13 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLOU-0007Hv-1F for simple@optimus.ietf.org; Thu, 13 Nov 2003 12:36:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09892 for ; Thu, 13 Nov 2003 12:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLOS-0001ex-00 for simple@ietf.org; Thu, 13 Nov 2003 12:36:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKLOR-0001eK-00 for simple@ietf.org; Thu, 13 Nov 2003 12:36:31 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADHaSA12119 for ; Thu, 13 Nov 2003 19:36:28 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 19:36:27 +0200 Received: from nokia.com ([10.162.15.98]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 19:36:27 +0200 Message-ID: <3FB3C11A.2020108@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on winfo-history References: <3FB35D77.1090508@dynamicsoft.com> In-Reply-To: <3FB35D77.1090508@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2003 17:36:27.0611 (UTC) FILETIME=[AAAA1AB0:01C3AA0C] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 19:36:26 +0200 Content-Transfer-Encoding: 7bit Hi Jonathan, That's actually a good point. The retroactive authorization (also mentioned in the draft) can clearly be solved by looking for the watchers whose state is "waiting". However, the 3GPP requirement reads: It must be possible for the presentity to fetch the list of the watchers who have accessed (by subscription or fetch) his presence information during a well-defined time- period (e.g. last 7 days). Event though there is no use case attached, I belive this is referring to something a bit different, like a "missed calls" type of log. And the draft also talks about winfo-history including events where a watcher entered the "terminated" state, with a timestamp of when it happened. So ther is clearly overlap and I think we need to discuss this bit in the SIMPLE session. Cheers, Aki ext Jonathan Rosenberg wrote: > A comment on: > http://www.ietf.org/internet-drafts/draft-niemi-simple-winfo-history-00.txt > > My apologies for not reading this and commenting sooner. > > The problem described in this draft is the exact reason why the > waiting state exists in the current winfo specifications. If a user is > pending, and then their susbcription expires, the information goes > into the waiting state, where it remains for a long time. The purpose > of that is for a user to find out who attempted to subscribe when they > were offline. > > Quoting from the winfo package: > >> The waiting state is similar to pending, in that no notifications are >> generated. However, if the subscription is approved or denied, the >> FSM is destroyed. The purpose of the waiting state is so that a user >> can fetch watcherinfo state at any time, and learn of any >> subscriptions that arrived previously (and which may arrive again) >> which require an authorization decision. Consider an example. A >> subscribes to B. B has not defined policy about this subscription, so >> it moves into the pending state. B is not "online", so that B's >> software agent cannot be contacted to approve the subscription. The >> subscription expires. Let's say it were destroyed. B logs in, and >> fetches its watcherinfo state. There is no record of the subscription >> from A, so no policy decision is made about subscriptions from A. B >> logs off. A refreshes its subscription. Once more, the subscription >> is pending since no policy is defined for it. This process could >> continue indefinitely. The waiting state ensures that B can find out >> about this subscription attempt. > > > I believe this meets your needs as specified. > > Thanks, > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 12:37:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09935 for ; Thu, 13 Nov 2003 12:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLP3-0007Kv-5y for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 12:37:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADHb8Lt028195 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 12:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLP2-0007Kd-OL for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 12:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09900; Thu, 13 Nov 2003 12:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLP0-0001fG-00; Thu, 13 Nov 2003 12:37:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKLOz-0001fD-00; Thu, 13 Nov 2003 12:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLOv-0007J8-Bi; Thu, 13 Nov 2003 12:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKLOU-0007Hv-1F for simple@optimus.ietf.org; Thu, 13 Nov 2003 12:36:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09892 for ; Thu, 13 Nov 2003 12:36:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKLOS-0001ex-00 for simple@ietf.org; Thu, 13 Nov 2003 12:36:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKLOR-0001eK-00 for simple@ietf.org; Thu, 13 Nov 2003 12:36:31 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADHaSA12119 for ; Thu, 13 Nov 2003 19:36:28 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 19:36:27 +0200 Received: from nokia.com ([10.162.15.98]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 19:36:27 +0200 Message-ID: <3FB3C11A.2020108@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] comments on winfo-history References: <3FB35D77.1090508@dynamicsoft.com> In-Reply-To: <3FB35D77.1090508@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2003 17:36:27.0611 (UTC) FILETIME=[AAAA1AB0:01C3AA0C] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 19:36:26 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, That's actually a good point. The retroactive authorization (also mentioned in the draft) can clearly be solved by looking for the watchers whose state is "waiting". However, the 3GPP requirement reads: It must be possible for the presentity to fetch the list of the watchers who have accessed (by subscription or fetch) his presence information during a well-defined time- period (e.g. last 7 days). Event though there is no use case attached, I belive this is referring to something a bit different, like a "missed calls" type of log. And the draft also talks about winfo-history including events where a watcher entered the "terminated" state, with a timestamp of when it happened. So ther is clearly overlap and I think we need to discuss this bit in the SIMPLE session. Cheers, Aki ext Jonathan Rosenberg wrote: > A comment on: > http://www.ietf.org/internet-drafts/draft-niemi-simple-winfo-history-00.txt > > My apologies for not reading this and commenting sooner. > > The problem described in this draft is the exact reason why the > waiting state exists in the current winfo specifications. If a user is > pending, and then their susbcription expires, the information goes > into the waiting state, where it remains for a long time. The purpose > of that is for a user to find out who attempted to subscribe when they > were offline. > > Quoting from the winfo package: > >> The waiting state is similar to pending, in that no notifications are >> generated. However, if the subscription is approved or denied, the >> FSM is destroyed. The purpose of the waiting state is so that a user >> can fetch watcherinfo state at any time, and learn of any >> subscriptions that arrived previously (and which may arrive again) >> which require an authorization decision. Consider an example. A >> subscribes to B. B has not defined policy about this subscription, so >> it moves into the pending state. B is not "online", so that B's >> software agent cannot be contacted to approve the subscription. The >> subscription expires. Let's say it were destroyed. B logs in, and >> fetches its watcherinfo state. There is no record of the subscription >> from A, so no policy decision is made about subscriptions from A. B >> logs off. A refreshes its subscription. Once more, the subscription >> is pending since no policy is defined for it. This process could >> continue indefinitely. The waiting state ensures that B can find out >> about this subscription attempt. > > > I believe this meets your needs as specified. > > Thanks, > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 14:08:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13191; Thu, 13 Nov 2003 14:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMpx-00032c-00; Thu, 13 Nov 2003 14:09:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKMpx-00032Z-00; Thu, 13 Nov 2003 14:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMpy-0004os-Sy; Thu, 13 Nov 2003 14:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMpB-0004f3-R6 for simple@optimus.ietf.org; Thu, 13 Nov 2003 14:08:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13154 for ; Thu, 13 Nov 2003 14:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMp9-00031k-00 for simple@ietf.org; Thu, 13 Nov 2003 14:08:11 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKMp8-000316-00 for simple@ietf.org; Thu, 13 Nov 2003 14:08:10 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2003 11:10:06 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hADJ7eFx019540 for ; Thu, 13 Nov 2003 11:07:40 -0800 (PST) Received: from [130.129.129.178] (rtp-vpn1-41.cisco.com [10.82.224.41]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJX82321; Thu, 13 Nov 2003 11:07:34 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-lonnfors-simple-prescaps-ext Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 08:59:37 -0800 Content-Transfer-Encoding: 7bit I don't really like the list of specific types of actors. Section 3.5 - typo - Definition of Data claims that it means it support "audio data" but should probably be "data". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 14:09:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13254 for ; Thu, 13 Nov 2003 14:09:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMq1-0004qL-R7 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 14:09:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJ95j5018611 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 14:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMq1-0004q6-Ky for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 14:09:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13191; Thu, 13 Nov 2003 14:08:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMpx-00032c-00; Thu, 13 Nov 2003 14:09:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKMpx-00032Z-00; Thu, 13 Nov 2003 14:09:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMpy-0004os-Sy; Thu, 13 Nov 2003 14:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMpB-0004f3-R6 for simple@optimus.ietf.org; Thu, 13 Nov 2003 14:08:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13154 for ; Thu, 13 Nov 2003 14:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMp9-00031k-00 for simple@ietf.org; Thu, 13 Nov 2003 14:08:11 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKMp8-000316-00 for simple@ietf.org; Thu, 13 Nov 2003 14:08:10 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 13 Nov 2003 11:10:06 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hADJ7eFx019540 for ; Thu, 13 Nov 2003 11:07:40 -0800 (PST) Received: from [130.129.129.178] (rtp-vpn1-41.cisco.com [10.82.224.41]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJX82321; Thu, 13 Nov 2003 11:07:34 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on draft-lonnfors-simple-prescaps-ext Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 08:59:37 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't really like the list of specific types of actors. Section 3.5 - typo - Definition of Data claims that it means it support "audio data" but should probably be "data". _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 14:37:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14723; Thu, 13 Nov 2003 14:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNI2-0003a9-00; Thu, 13 Nov 2003 14:38:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNI1-0003a6-00; Thu, 13 Nov 2003 14:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNI1-0007Us-Hq; Thu, 13 Nov 2003 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNHm-0007Qp-4P for simple@optimus.ietf.org; Thu, 13 Nov 2003 14:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14719 for ; Thu, 13 Nov 2003 14:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNHj-0003Zz-00 for simple@ietf.org; Thu, 13 Nov 2003 14:37:43 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKNHi-0003ZO-00 for simple@ietf.org; Thu, 13 Nov 2003 14:37:42 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hADJb8Gd026717 for ; Thu, 13 Nov 2003 13:37:08 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 13:37:08 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86608@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] XCAP content types Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 13:37:05 -0600 I wanted to take this to the list to see if we get more feedback. One of the open issues with XCAP is: what Content-Type is indicated in XCAP GET and PUT requests? My proposal is: - If the document being fetched is a complete document, label the content correctly. For these operations, these are essentially the same as non-XCAP operations. In particular, I should be able to hand an XCAP URL to a normal HTTP client, have it fetch it, and know how to handle the content. Content-Type: application/foo+xml - If the document being fetched is a part of an XML document, we should have a Content-Type that indicates that the content is a partial XML document (e.g. "xml-snippet"). I note that RFC 2045 allows subtypes to define their own parameters. For the proposed subtype, I would additionally propose a parameter that indicates the content-type of the root document. Content-Type: application/xml-snippet;root="application/foo+xml" /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 14:38:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14755 for ; Thu, 13 Nov 2003 14:38:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNI6-0007X9-Pz for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 14:38:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJc6xi028933 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 14:38:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNI6-0007Wa-0Q for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 14:38:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14723; Thu, 13 Nov 2003 14:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNI2-0003a9-00; Thu, 13 Nov 2003 14:38:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNI1-0003a6-00; Thu, 13 Nov 2003 14:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNI1-0007Us-Hq; Thu, 13 Nov 2003 14:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNHm-0007Qp-4P for simple@optimus.ietf.org; Thu, 13 Nov 2003 14:37:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14719 for ; Thu, 13 Nov 2003 14:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNHj-0003Zz-00 for simple@ietf.org; Thu, 13 Nov 2003 14:37:43 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKNHi-0003ZO-00 for simple@ietf.org; Thu, 13 Nov 2003 14:37:42 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hADJb8Gd026717 for ; Thu, 13 Nov 2003 13:37:08 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Nov 2003 13:37:08 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86608@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] XCAP content types Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 13:37:05 -0600 I wanted to take this to the list to see if we get more feedback. One of the open issues with XCAP is: what Content-Type is indicated in XCAP GET and PUT requests? My proposal is: - If the document being fetched is a complete document, label the content correctly. For these operations, these are essentially the same as non-XCAP operations. In particular, I should be able to hand an XCAP URL to a normal HTTP client, have it fetch it, and know how to handle the content. Content-Type: application/foo+xml - If the document being fetched is a part of an XML document, we should have a Content-Type that indicates that the content is a partial XML document (e.g. "xml-snippet"). I note that RFC 2045 allows subtypes to define their own parameters. For the proposed subtype, I would additionally propose a parameter that indicates the content-type of the root document. Content-Type: application/xml-snippet;root="application/foo+xml" /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 14:52:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15322; Thu, 13 Nov 2003 14:52:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNWY-0003mT-00; Thu, 13 Nov 2003 14:53:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNWX-0003mQ-00; Thu, 13 Nov 2003 14:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNWW-0008A8-T0; Thu, 13 Nov 2003 14:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNVw-00089a-Qs for simple@optimus.ietf.org; Thu, 13 Nov 2003 14:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15295 for ; Thu, 13 Nov 2003 14:52:12 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNVt-0003m6-00 for simple@ietf.org; Thu, 13 Nov 2003 14:52:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKNVt-0003m3-00 for simple@ietf.org; Thu, 13 Nov 2003 14:52:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADJqKA25905 for ; Thu, 13 Nov 2003 21:52:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 21:52:19 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Nov 2003 21:52:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on draft-lonnfors-simple-prescaps-ext Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17252@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-lonnfors-simple-prescaps-ext Thread-Index: AcOqGcPpw3Q+QXgZRj2+AN7SXIbYRAABO8Tg To: , X-OriginalArrivalTime: 13 Nov 2003 19:52:19.0832 (UTC) FILETIME=[A5C44F80:01C3AA1F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 21:52:19 +0200 Content-Transfer-Encoding: quoted-printable Hi Cullen, >=20 > I don't really like the list of specific types of actors. These definitions have been taken from draft-ietf-sip-callee-caps-01. I am not sure if it is feasible to change those definitions in the context of prescaps draft. Of course if some of those doesn't make sense they could be removed.=20 Did you have some specific issue in mind?=20 > Section 3.5 - typo - Definition of Data claims that it means=20 > it support "audio data" but should probably be "data". Will be fixed. - Mikko=20 >=20 >=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 exim@www1.ietf.org Thu Nov 13 14:53:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15349 for ; Thu, 13 Nov 2003 14:53:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNWc-0008At-SD for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 14:53:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJr6Px031422 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 14:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNWc-0008Aj-Mg for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 14:53:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15322; Thu, 13 Nov 2003 14:52:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNWY-0003mT-00; Thu, 13 Nov 2003 14:53:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKNWX-0003mQ-00; Thu, 13 Nov 2003 14:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNWW-0008A8-T0; Thu, 13 Nov 2003 14:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKNVw-00089a-Qs for simple@optimus.ietf.org; Thu, 13 Nov 2003 14:52:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15295 for ; Thu, 13 Nov 2003 14:52:12 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKNVt-0003m6-00 for simple@ietf.org; Thu, 13 Nov 2003 14:52:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKNVt-0003m3-00 for simple@ietf.org; Thu, 13 Nov 2003 14:52:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADJqKA25905 for ; Thu, 13 Nov 2003 21:52:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 21:52:19 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 13 Nov 2003 21:52:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Comments on draft-lonnfors-simple-prescaps-ext Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17252@esebe004.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-lonnfors-simple-prescaps-ext Thread-Index: AcOqGcPpw3Q+QXgZRj2+AN7SXIbYRAABO8Tg To: , X-OriginalArrivalTime: 13 Nov 2003 19:52:19.0832 (UTC) FILETIME=[A5C44F80:01C3AA1F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 21:52:19 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Cullen, >=20 > I don't really like the list of specific types of actors. These definitions have been taken from draft-ietf-sip-callee-caps-01. I am not sure if it is feasible to change those definitions in the context of prescaps draft. Of course if some of those doesn't make sense they could be removed.=20 Did you have some specific issue in mind?=20 > Section 3.5 - typo - Definition of Data claims that it means=20 > it support "audio data" but should probably be "data". Will be fixed. - Mikko=20 >=20 >=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-admin@ietf.org Thu Nov 13 18:37:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29644; Thu, 13 Nov 2003 18:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000Hj-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000HY-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2I-0001kF-OH; Thu, 13 Nov 2003 18:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR1y-0001h2-O4 for simple@optimus.ietf.org; Thu, 13 Nov 2003 18:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29627 for ; Thu, 13 Nov 2003 18:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR1v-0000HO-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKR1v-0000Gd-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Nov 2003 15:44:17 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADNb7Av028196; Thu, 13 Nov 2003 15:37:09 -0800 (PST) Received: from [130.129.129.178] (sjc-vpn3-209.cisco.com [10.21.64.209]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJY15317; Thu, 13 Nov 2003 15:37:06 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP Comments From: Cullen Jennings To: Adam Roach CC: "'simple@ietf.org'" Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865E0@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 15:12:08 -0800 Content-Transfer-Encoding: 7bit How do you do this on an OS that only supports a single byte peek? I imagine there is a way to push the bytes into the SSL buffer but not sure how. I do love when you send code, it always makes my day, but my question was not could you do this but why would you not do it the other way. Cullen On 11/10/03 11:46 AM, "Adam Roach" wrote: > Cullen Jennings writes: > >> I'm very suspicious that the look ahead scheme to switch to >> TLS is going to be very hard to integrate with existing >> libraries > > Like OpenSSL? > > int Msrp::read(char *buffer, int maxLen) > { > int len; > int magic; > > if (!usingSsl) > { > len = recv(s, &magic, 4, MSG_PEEK); > > if ((htonl(magic) >> 8) == 0x160301) > { > SSL_set_fd(ssl, s); > usingSsl = true; > } > else > { > len = read(s, buffer, maxLen); > } > } > > if (usingSsl) > { > len = SSL_read(ssl, buffer, maxLen); > } > > return len; > } > > (modulo error checking) > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 18:38:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29695 for ; Thu, 13 Nov 2003 18:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2P-0001pS-JZ for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 18:38:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADNc8jK006854 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 18:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2O-0001mS-05 for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:38:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29641; Thu, 13 Nov 2003 18:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000Hg-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000HZ-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2I-0001k7-0V; Thu, 13 Nov 2003 18:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR1v-0001fp-Pv for simple@optimus.ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29621 for ; Thu, 13 Nov 2003 18:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR1s-0000HD-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:36 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKR1s-0000Gc-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:36 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADNb4At028130; Thu, 13 Nov 2003 15:37:04 -0800 (PST) Received: from [130.129.129.178] (sjc-vpn3-209.cisco.com [10.21.64.209]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJY15310; Thu, 13 Nov 2003 15:37:03 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] Comments on draft-lonnfors-simple-prescaps-ext From: Cullen Jennings To: , Message-ID: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17252@esebe004.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 14:16:08 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ahhh, I see my confusion now sorry. I think the text "The element indicates that the UA is a conference server, also known as a focus, and will mix together the media for all calls to the same URI as ... " might be wrong. might be wrong. Does this really only apply to a conference server. Could just a normal UA act as "information". Either way, I see why you mirrored callee-caps and agree that is the right thing to do. Cullen On 11/13/03 11:52 AM, "mikko.lonnfors@nokia.com" wrote: > Hi Cullen, > >> >> I don't really like the list of specific types of actors. > > These definitions have been taken from draft-ietf-sip-callee-caps-01. I > am not sure if it is feasible to change those definitions in the context > of prescaps draft. Of course if some of those doesn't make sense they > could be removed. > Did you have some specific issue in mind? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 13 18:38:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29696 for ; Thu, 13 Nov 2003 18:38:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2P-0001pT-Kk for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 18:38:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADNc8cQ006870 for simple-archive@odin.ietf.org; Thu, 13 Nov 2003 18:38:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2O-0001mU-5M for simple-web-archive@optimus.ietf.org; Thu, 13 Nov 2003 18:38:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29644; Thu, 13 Nov 2003 18:37:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000Hj-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000HY-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2I-0001kF-OH; Thu, 13 Nov 2003 18:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR1y-0001h2-O4 for simple@optimus.ietf.org; Thu, 13 Nov 2003 18:37:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29627 for ; Thu, 13 Nov 2003 18:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR1v-0000HO-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKR1v-0000Gd-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Nov 2003 15:44:17 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADNb7Av028196; Thu, 13 Nov 2003 15:37:09 -0800 (PST) Received: from [130.129.129.178] (sjc-vpn3-209.cisco.com [10.21.64.209]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJY15317; Thu, 13 Nov 2003 15:37:06 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP Comments From: Cullen Jennings To: Adam Roach CC: "'simple@ietf.org'" Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865E0@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 15:12:08 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit How do you do this on an OS that only supports a single byte peek? I imagine there is a way to push the bytes into the SSL buffer but not sure how. I do love when you send code, it always makes my day, but my question was not could you do this but why would you not do it the other way. Cullen On 11/10/03 11:46 AM, "Adam Roach" wrote: > Cullen Jennings writes: > >> I'm very suspicious that the look ahead scheme to switch to >> TLS is going to be very hard to integrate with existing >> libraries > > Like OpenSSL? > > int Msrp::read(char *buffer, int maxLen) > { > int len; > int magic; > > if (!usingSsl) > { > len = recv(s, &magic, 4, MSG_PEEK); > > if ((htonl(magic) >> 8) == 0x160301) > { > SSL_set_fd(ssl, s); > usingSsl = true; > } > else > { > len = read(s, buffer, maxLen); > } > } > > if (usingSsl) > { > len = SSL_read(ssl, buffer, maxLen); > } > > return len; > } > > (modulo error checking) > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 13 19:41:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29641; Thu, 13 Nov 2003 18:37:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000Hg-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKR2J-0000HZ-00; Thu, 13 Nov 2003 18:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2I-0001k7-0V; Thu, 13 Nov 2003 18:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR1v-0001fp-Pv for simple@optimus.ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29621 for ; Thu, 13 Nov 2003 18:37:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR1s-0000HD-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:36 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKR1s-0000Gc-00 for simple@ietf.org; Thu, 13 Nov 2003 18:37:36 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADNb4At028130; Thu, 13 Nov 2003 15:37:04 -0800 (PST) Received: from [130.129.129.178] (sjc-vpn3-209.cisco.com [10.21.64.209]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJY15310; Thu, 13 Nov 2003 15:37:03 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] Comments on draft-lonnfors-simple-prescaps-ext From: Cullen Jennings To: , Message-ID: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17252@esebe004.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 14:16:08 -0800 Content-Transfer-Encoding: 7bit Ahhh, I see my confusion now sorry. I think the text "The element indicates that the UA is a conference server, also known as a focus, and will mix together the media for all calls to the same URI as ... " might be wrong. might be wrong. Does this really only apply to a conference server. Could just a normal UA act as "information". Either way, I see why you mirrored callee-caps and agree that is the right thing to do. Cullen On 11/13/03 11:52 AM, "mikko.lonnfors@nokia.com" wrote: > Hi Cullen, > >> >> I don't really like the list of specific types of actors. > > These definitions have been taken from draft-ietf-sip-callee-caps-01. I > am not sure if it is feasible to change those definitions in the context > of prescaps draft. Of course if some of those doesn't make sense they > could be removed. > Did you have some specific issue in mind? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 14 10:12:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13922; Fri, 14 Nov 2003 10:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfdC-0006c2-00; Fri, 14 Nov 2003 10:13:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKfdC-0006bz-00; Fri, 14 Nov 2003 10:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfd8-0004vE-G8; Fri, 14 Nov 2003 10:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfd0-0004uj-1c for simple@optimus.ietf.org; Fri, 14 Nov 2003 10:12:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13845 for ; Fri, 14 Nov 2003 10:12:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfcw-0006ac-00 for simple@ietf.org; Fri, 14 Nov 2003 10:12:50 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKfcw-0006Xc-00 for simple@ietf.org; Fri, 14 Nov 2003 10:12:50 -0500 Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAEFC9d03535; Fri, 14 Nov 2003 09:12:09 -0600 From: Robert Sparks To: sip-implementors@cs.columbia.edu, simple@ietf.org Content-Type: text/plain Message-Id: <1068822728.1069.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt registration closes tomorrow Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 09:12:08 -0600 Content-Transfer-Encoding: 7bit SIMPLEt registration closes tomorrow. If you are bringing an implementation and haven't told us yet, now is the time. RjS (See http://simplet.jasomi.com and http://www.sipit.net for more information). _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 14 10:13:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14099 for ; Fri, 14 Nov 2003 10:13:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfdG-0004xk-GS for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 10:13:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFDAWv019070 for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 10:13:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfdG-0004xV-BV for simple-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:13:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13922; Fri, 14 Nov 2003 10:12:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfdC-0006c2-00; Fri, 14 Nov 2003 10:13:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKfdC-0006bz-00; Fri, 14 Nov 2003 10:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfd8-0004vE-G8; Fri, 14 Nov 2003 10:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKfd0-0004uj-1c for simple@optimus.ietf.org; Fri, 14 Nov 2003 10:12:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13845 for ; Fri, 14 Nov 2003 10:12:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKfcw-0006ac-00 for simple@ietf.org; Fri, 14 Nov 2003 10:12:50 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKfcw-0006Xc-00 for simple@ietf.org; Fri, 14 Nov 2003 10:12:50 -0500 Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAEFC9d03535; Fri, 14 Nov 2003 09:12:09 -0600 From: Robert Sparks To: sip-implementors@cs.columbia.edu, simple@ietf.org Content-Type: text/plain Message-Id: <1068822728.1069.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt registration closes tomorrow Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 09:12:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIMPLEt registration closes tomorrow. If you are bringing an implementation and haven't told us yet, now is the time. RjS (See http://simplet.jasomi.com and http://www.sipit.net for more information). _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 14 10:39:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16281; Fri, 14 Nov 2003 10:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg3P-0007MZ-00; Fri, 14 Nov 2003 10:40:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKg3O-0007MW-00; Fri, 14 Nov 2003 10:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3I-000881-Nm; Fri, 14 Nov 2003 10:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3C-000870-HO for simple@optimus.ietf.org; Fri, 14 Nov 2003 10:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16256 for ; Fri, 14 Nov 2003 10:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg39-0007Lt-00 for simple@ietf.org; Fri, 14 Nov 2003 10:39:55 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKg39-0007LN-00 for simple@ietf.org; Fri, 14 Nov 2003 10:39:55 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAEFdFGd001528; Fri, 14 Nov 2003 09:39:16 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Nov 2003 09:39:16 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86616@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach Cc: "'simple@ietf.org'" Subject: RE: [Simple] MSRP Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 09:39:14 -0600 Cullen Jennings [mailto:fluffy@cisco.com] wrote: > How do you do this on an OS that only supports a single byte > peek? As long as you're doing framing the obvious way (i.e., read the leader line to get the message size, and then blindly read that many bytes), then you can simply check whether the first byte is 0x16 (not valid in an MSRP leader line). > I do love when you send code, it always makes my day, but my > question was not could you do this but why would you not do > it the other way. No, you expressed a concern that a switch to TLS would not be easy to integrate with existing libraries. I included code to show how easy it is, since that seems more compelling than just saying, "no, you're wrong." /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 14 10:40:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16391 for ; Fri, 14 Nov 2003 10:40:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3V-0008Ay-IW for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 10:40:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEFeGHE031422 for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 10:40:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3T-0008Aj-30 for simple-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 10:40:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16281; Fri, 14 Nov 2003 10:39:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg3P-0007MZ-00; Fri, 14 Nov 2003 10:40:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKg3O-0007MW-00; Fri, 14 Nov 2003 10:40:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3I-000881-Nm; Fri, 14 Nov 2003 10:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKg3C-000870-HO for simple@optimus.ietf.org; Fri, 14 Nov 2003 10:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16256 for ; Fri, 14 Nov 2003 10:39:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKg39-0007Lt-00 for simple@ietf.org; Fri, 14 Nov 2003 10:39:55 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AKg39-0007LN-00 for simple@ietf.org; Fri, 14 Nov 2003 10:39:55 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAEFdFGd001528; Fri, 14 Nov 2003 09:39:16 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Nov 2003 09:39:16 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86616@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach Cc: "'simple@ietf.org'" Subject: RE: [Simple] MSRP Comments MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 09:39:14 -0600 Cullen Jennings [mailto:fluffy@cisco.com] wrote: > How do you do this on an OS that only supports a single byte > peek? As long as you're doing framing the obvious way (i.e., read the leader line to get the message size, and then blindly read that many bytes), then you can simply check whether the first byte is 0x16 (not valid in an MSRP leader line). > I do love when you send code, it always makes my day, but my > question was not could you do this but why would you not do > it the other way. No, you expressed a concern that a switch to TLS would not be easy to integrate with existing libraries. I included code to show how easy it is, since that seems more compelling than just saying, "no, you're wrong." /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 14 13:07:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22766; Fri, 14 Nov 2003 13:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiMa-00021x-00; Fri, 14 Nov 2003 13:08:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKiMZ-00021u-00; Fri, 14 Nov 2003 13:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiMU-0003bn-DQ; Fri, 14 Nov 2003 13:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiMG-0003RX-2x for simple@optimus.ietf.org; Fri, 14 Nov 2003 13:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22709 for ; Fri, 14 Nov 2003 13:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiMD-000216-00 for simple@ietf.org; Fri, 14 Nov 2003 13:07:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AKiMD-000212-00 for simple@ietf.org; Fri, 14 Nov 2003 13:07:45 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEI7i602730 for ; Fri, 14 Nov 2003 20:07:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Nov 2003 20:07:43 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 20:07:43 +0200 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA06683; Fri, 14 Nov 2003 20:07:46 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAEK74iZ007609; Fri, 14 Nov 2003 22:07:04 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hAEK731f007608; Fri, 14 Nov 2003 22:07:03 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Cc: Simple WG X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3FAFB77F.2080903@dynamicsoft.com> (Jonathan Rosenberg's message of "Mon, 10 Nov 2003 11:06:23 -0500") References: <3FAFB77F.2080903@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 14 Nov 2003 18:07:43.0829 (UTC) FILETIME=[33640050:01C3AADA] Subject: [Simple] Using XCAP to manipulate well-formed presence information Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 22:07:03 +0200 Hello all, Just another comment regarding XCAP and Markus' and Eva's draft, raised by Jari Urpalainen. CPIM-PIDF is well-formed XML document. It can be extended just by giving a name space URI of you extension. No schema required. However, XCAP requires that the XML document it handles have a schema and that all the documents are valid. I guess the intention is that all the XCAP data has either a DTD or an XML schema. Now the question is, do we want to limit the permanently published presence documents to a particular schema? Or is it possible to define publication-AU that has multiple schema? In any case, it seems to defeat the only good side of CPIM-PIDF... BR, Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 14 13:08:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22845 for ; Fri, 14 Nov 2003 13:08:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiMd-0003eG-Vo for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 13:08:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEI8B7B014020 for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 13:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiMd-0003e3-B5 for simple-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 13:08:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22766; Fri, 14 Nov 2003 13:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiMa-00021x-00; Fri, 14 Nov 2003 13:08:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKiMZ-00021u-00; Fri, 14 Nov 2003 13:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiMU-0003bn-DQ; Fri, 14 Nov 2003 13:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKiMG-0003RX-2x for simple@optimus.ietf.org; Fri, 14 Nov 2003 13:07:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22709 for ; Fri, 14 Nov 2003 13:07:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKiMD-000216-00 for simple@ietf.org; Fri, 14 Nov 2003 13:07:46 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AKiMD-000212-00 for simple@ietf.org; Fri, 14 Nov 2003 13:07:45 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAEI7i602730 for ; Fri, 14 Nov 2003 20:07:44 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Nov 2003 20:07:43 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 20:07:43 +0200 Received: from localhost.localdomain (hed042-227.research.nokia.com [172.21.42.227]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA06683; Fri, 14 Nov 2003 20:07:46 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hAEK74iZ007609; Fri, 14 Nov 2003 22:07:04 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hAEK731f007608; Fri, 14 Nov 2003 22:07:03 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Jonathan Rosenberg Cc: Simple WG X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3FAFB77F.2080903@dynamicsoft.com> (Jonathan Rosenberg's message of "Mon, 10 Nov 2003 11:06:23 -0500") References: <3FAFB77F.2080903@dynamicsoft.com> Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 14 Nov 2003 18:07:43.0829 (UTC) FILETIME=[33640050:01C3AADA] Subject: [Simple] Using XCAP to manipulate well-formed presence information Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 22:07:03 +0200 Hello all, Just another comment regarding XCAP and Markus' and Eva's draft, raised by Jari Urpalainen. CPIM-PIDF is well-formed XML document. It can be extended just by giving a name space URI of you extension. No schema required. However, XCAP requires that the XML document it handles have a schema and that all the documents are valid. I guess the intention is that all the XCAP data has either a DTD or an XML schema. Now the question is, do we want to limit the permanently published presence documents to a particular schema? Or is it possible to define publication-AU that has multiple schema? In any case, it seems to defeat the only good side of CPIM-PIDF... BR, Pekka _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 14 14:30:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25472; Fri, 14 Nov 2003 14:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjej-0003AM-00; Fri, 14 Nov 2003 14:30:57 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AKjYW-00031k-02; Fri, 14 Nov 2003 14:24:32 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AKjPQ-0001hC-Qm; Fri, 14 Nov 2003 14:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjPL-0000nF-Kq; Fri, 14 Nov 2003 14:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjPD-0000mh-H3 for simple@optimus.ietf.org; Fri, 14 Nov 2003 14:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24927 for ; Fri, 14 Nov 2003 14:14:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjPA-0002ud-00 for simple@ietf.org; Fri, 14 Nov 2003 14:14:52 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AKjPA-0002ua-00 for simple@ietf.org; Fri, 14 Nov 2003 14:14:52 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hAEJEq302412; Fri, 14 Nov 2003 14:14:52 -0500 To: Adam Roach Cc: simple@ietf.org Subject: Re: [Simple] XCAP content types References: <9BF66EBF6BEFD942915B4D4D45C051F3E86608@dyn-tx-exch-001.dynamicsoft.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86608@dyn-tx-exch-001.dynamicsoft.com> (Adam Roach's message of "Thu, 13 Nov 2003 13:37:05 -0600") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 14:14:52 -0500 Adam Roach writes: > - If the document being fetched is a part of an XML > document, we should have a Content-Type that > indicates that the content is a partial XML document > (e.g. "xml-snippet"). I note that RFC 2045 allows > subtypes to define their own parameters. For the > proposed subtype, I would additionally propose a > parameter that indicates the content-type of the > root document. > > Content-Type: application/xml-snippet;root="application/foo+xml" W3C calls these XML Fragments [1], so application/xml-fragment might be mor in line with that. They just use the mime type text/xml for them. I rather link the idea of qualifying the type, though. [1] http://www.w3.org/TR/xml-fragment -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 14 14:31:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25567 for ; Fri, 14 Nov 2003 14:31:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjeo-0001cP-Q8 for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 14:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEJV2kl006215 for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 14:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjeo-0001c3-HM for simple-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 14:31:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25472; Fri, 14 Nov 2003 14:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjej-0003AM-00; Fri, 14 Nov 2003 14:30:57 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AKjYW-00031k-02; Fri, 14 Nov 2003 14:24:32 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AKjPQ-0001hC-Qm; Fri, 14 Nov 2003 14:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjPL-0000nF-Kq; Fri, 14 Nov 2003 14:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKjPD-0000mh-H3 for simple@optimus.ietf.org; Fri, 14 Nov 2003 14:14:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24927 for ; Fri, 14 Nov 2003 14:14:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKjPA-0002ud-00 for simple@ietf.org; Fri, 14 Nov 2003 14:14:52 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AKjPA-0002ua-00 for simple@ietf.org; Fri, 14 Nov 2003 14:14:52 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hAEJEq302412; Fri, 14 Nov 2003 14:14:52 -0500 To: Adam Roach Cc: simple@ietf.org Subject: Re: [Simple] XCAP content types References: <9BF66EBF6BEFD942915B4D4D45C051F3E86608@dyn-tx-exch-001.dynamicsoft.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86608@dyn-tx-exch-001.dynamicsoft.com> (Adam Roach's message of "Thu, 13 Nov 2003 13:37:05 -0600") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 14:14:52 -0500 Adam Roach writes: > - If the document being fetched is a part of an XML > document, we should have a Content-Type that > indicates that the content is a partial XML document > (e.g. "xml-snippet"). I note that RFC 2045 allows > subtypes to define their own parameters. For the > proposed subtype, I would additionally propose a > parameter that indicates the content-type of the > root document. > > Content-Type: application/xml-snippet;root="application/foo+xml" W3C calls these XML Fragments [1], so application/xml-fragment might be mor in line with that. They just use the mime type text/xml for them. I rather link the idea of qualifying the type, though. [1] http://www.w3.org/TR/xml-fragment -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 14 16:50:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00596; Fri, 14 Nov 2003 16:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKlqO-0004rL-00; Fri, 14 Nov 2003 16:51:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKlqN-0004rI-00; Fri, 14 Nov 2003 16:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlqI-0002vm-62; Fri, 14 Nov 2003 16:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlpj-0002uQ-0S for simple@optimus.ietf.org; Fri, 14 Nov 2003 16:50:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00569 for ; Fri, 14 Nov 2003 16:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKlpg-0004qM-00 for simple@ietf.org; Fri, 14 Nov 2003 16:50:24 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1AKlpY-0004q4-00 for simple@ietf.org; Fri, 14 Nov 2003 16:50:24 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Fri, 14 Nov 2003 21:18:03 +0530 Delivered-To: ipgen-india.com-lakshmi@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 13853 invoked by uid 7010); Fri Nov 14 21:00:34 2003 Received: (sifymail 13851 invoked by uid 7010); 14 Nov 2003 21:00:34 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 14 Nov 2003 21:00:34 +0530 Received: (sifymail 21733 invoked by uid 7005); 14 Nov 2003 21:00:34 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 14 Nov 2003 21:00:34 +0530 Received: (sifymail 21728 invoked by uid 7005); 14 Nov 2003 21:00:33 +0530 Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73) by 202.144.76.19 with SMTP; 14 Nov 2003 21:00:33 +0530 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1AKfcn-0000R2-00; Fri, 14 Nov 2003 10:12:41 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAEFCI9D026321 for ; Fri, 14 Nov 2003 10:12:18 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) id hAEFC9d03535; Fri, 14 Nov 2003 09:12:09 -0600 From: Robert Sparks To: sip-implementors@cs.columbia.edu, simple@ietf.org Content-Type: text/plain Message-Id: <1068822728.1069.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip-implementors] SIMPLEt registration closes tomorrow Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 09:12:08 -0600 Content-Transfer-Encoding: 7bit SIMPLEt registration closes tomorrow. If you are bringing an implementation and haven't told us yet, now is the time. RjS (See http://simplet.jasomi.com and http://www.sipit.net for more information). _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 14 16:51:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00651 for ; Fri, 14 Nov 2003 16:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlqS-0002x4-4Z for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 16:51:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAELpCCZ011340 for simple-archive@odin.ietf.org; Fri, 14 Nov 2003 16:51:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlqS-0002wp-1M for simple-web-archive@optimus.ietf.org; Fri, 14 Nov 2003 16:51:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00596; Fri, 14 Nov 2003 16:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKlqO-0004rL-00; Fri, 14 Nov 2003 16:51:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AKlqN-0004rI-00; Fri, 14 Nov 2003 16:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlqI-0002vm-62; Fri, 14 Nov 2003 16:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKlpj-0002uQ-0S for simple@optimus.ietf.org; Fri, 14 Nov 2003 16:50:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00569 for ; Fri, 14 Nov 2003 16:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKlpg-0004qM-00 for simple@ietf.org; Fri, 14 Nov 2003 16:50:24 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1AKlpY-0004q4-00 for simple@ietf.org; Fri, 14 Nov 2003 16:50:24 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Fri, 14 Nov 2003 21:18:03 +0530 Delivered-To: ipgen-india.com-lakshmi@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 13853 invoked by uid 7010); Fri Nov 14 21:00:34 2003 Received: (sifymail 13851 invoked by uid 7010); 14 Nov 2003 21:00:34 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 14 Nov 2003 21:00:34 +0530 Received: (sifymail 21733 invoked by uid 7005); 14 Nov 2003 21:00:34 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 14 Nov 2003 21:00:34 +0530 Received: (sifymail 21728 invoked by uid 7005); 14 Nov 2003 21:00:33 +0530 Received: from 128.59.16.73 (HELO rogue.cs.columbia.edu) (128.59.16.73) by 202.144.76.19 with SMTP; 14 Nov 2003 21:00:33 +0530 Received: from cs.columbia.edu ([128.59.16.20]) by rogue.cs.columbia.edu with esmtp (Exim 4.12) id 1AKfcn-0000R2-00; Fri, 14 Nov 2003 10:12:41 -0500 Received: from dyn-tx-arch-crash.dfw.dynamicsoft.com ([63.110.3.64]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAEFCI9D026321 for ; Fri, 14 Nov 2003 10:12:18 -0500 (EST) Received: from RjS.localdomain (localhost.localdomain [127.0.0.1]) id hAEFC9d03535; Fri, 14 Nov 2003 09:12:09 -0600 From: Robert Sparks To: sip-implementors@cs.columbia.edu, simple@ietf.org Content-Type: text/plain Message-Id: <1068822728.1069.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit X-BeenThere: sip-implementors@cs.columbia.edu X-Mailman-Version: 2.1.1 Precedence: list X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Content-Transfer-Encoding: 7bit Subject: [Simple] [Sip-implementors] SIMPLEt registration closes tomorrow Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 14 Nov 2003 09:12:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit SIMPLEt registration closes tomorrow. If you are bringing an implementation and haven't told us yet, now is the time. RjS (See http://simplet.jasomi.com and http://www.sipit.net for more information). _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 15 19:32:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26641; Sat, 15 Nov 2003 19:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAqg-0000fc-00; Sat, 15 Nov 2003 19:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALAqf-0000fS-00; Sat, 15 Nov 2003 19:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAqb-0002KL-DX; Sat, 15 Nov 2003 19:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAq8-0002Jn-F8 for simple@optimus.ietf.org; Sat, 15 Nov 2003 19:32:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26595 for ; Sat, 15 Nov 2003 19:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAq6-0000ea-00 for simple@ietf.org; Sat, 15 Nov 2003 19:32:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAq6-0000eS-00 for simple@ietf.org; Sat, 15 Nov 2003 19:32:30 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAG0VwAt020464 for ; Sat, 15 Nov 2003 16:31:58 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-104.cisco.com [10.21.64.104]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ46723; Sat, 15 Nov 2003 16:31:57 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Objects to NATs kill TCP connection Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Nov 2003 16:31:56 -0800 Content-Transfer-Encoding: 7bit There was some assertion in the WG meeting that NATs arbitrarily kill TCP connection and the connection needs to be set up again. I'm sure this has happened with broken NATS but I do not feel it is widespread and don't think we should specifically design for it. I do think we should design for graceful failure or recover when things in the network fail but I don't think there is a common case of TCP failing that involves NATs. If there were, many things that do not automatically set up a new TCP connection, like ssh for example, would be nearly unusable through these broken NATs. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 15 19:33:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26665 for ; Sat, 15 Nov 2003 19:33:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAqj-0002N3-3Z for simple-archive@odin.ietf.org; Sat, 15 Nov 2003 19:33:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAG0X9DX009107 for simple-archive@odin.ietf.org; Sat, 15 Nov 2003 19:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAqi-0002Mo-V2 for simple-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 19:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26641; Sat, 15 Nov 2003 19:32:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAqg-0000fc-00; Sat, 15 Nov 2003 19:33:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALAqf-0000fS-00; Sat, 15 Nov 2003 19:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAqb-0002KL-DX; Sat, 15 Nov 2003 19:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAq8-0002Jn-F8 for simple@optimus.ietf.org; Sat, 15 Nov 2003 19:32:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26595 for ; Sat, 15 Nov 2003 19:32:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAq6-0000ea-00 for simple@ietf.org; Sat, 15 Nov 2003 19:32:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAq6-0000eS-00 for simple@ietf.org; Sat, 15 Nov 2003 19:32:30 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAG0VwAt020464 for ; Sat, 15 Nov 2003 16:31:58 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-104.cisco.com [10.21.64.104]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ46723; Sat, 15 Nov 2003 16:31:57 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Objects to NATs kill TCP connection Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Nov 2003 16:31:56 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit There was some assertion in the WG meeting that NATs arbitrarily kill TCP connection and the connection needs to be set up again. I'm sure this has happened with broken NATS but I do not feel it is widespread and don't think we should specifically design for it. I do think we should design for graceful failure or recover when things in the network fail but I don't think there is a common case of TCP failing that involves NATs. If there were, many things that do not automatically set up a new TCP connection, like ssh for example, would be nearly unusable through these broken NATs. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat Nov 15 19:34:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26709; Sat, 15 Nov 2003 19:34:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAsd-0000hQ-00; Sat, 15 Nov 2003 19:35:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALAsc-0000hN-00; Sat, 15 Nov 2003 19:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAsX-0002Qq-I2; Sat, 15 Nov 2003 19:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAs7-0002Q1-Dp for simple@optimus.ietf.org; Sat, 15 Nov 2003 19:34:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26690 for ; Sat, 15 Nov 2003 19:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAs5-0000gc-00 for simple@ietf.org; Sat, 15 Nov 2003 19:34:33 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAs4-0000gM-00 for simple@ietf.org; Sat, 15 Nov 2003 19:34:32 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Nov 2003 16:37:01 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAG0Y0tg014059; Sat, 15 Nov 2003 16:34:01 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-104.cisco.com [10.21.64.104]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ46747; Sat, 15 Nov 2003 16:33:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Adam Roach , "'Aki Niemi'" , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] IM and file transfer Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Nov 2003 16:33:57 -0800 Content-Transfer-Encoding: 7bit On 11/11/03 9:27 AM, "Adam Roach" wrote: > > Aki Niemi [mailto:aki.niemi@nokia.com] writes: > >> These are somewhat orthogonal aspects of a message session. It is >> probably useful to label a specific session as e.g., file-transfer > > Yes. You do this by using port 21. If you know a priori that all > you are going to do is transfer files, the IETF has already > defined a file transfer protocol. Yes, and FTP meets my end user to end user file transfer needs somewhat less well than IRC meets my IMPP needs. File transfer is a requirement for any viable modern IM application. FTP will still be used for places where it meets the needs. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Nov 15 19:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26745 for ; Sat, 15 Nov 2003 19:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAsg-0002Ux-G4 for simple-archive@odin.ietf.org; Sat, 15 Nov 2003 19:35:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAG0ZA4D009597 for simple-archive@odin.ietf.org; Sat, 15 Nov 2003 19:35:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAsg-0002Ui-Bt for simple-web-archive@optimus.ietf.org; Sat, 15 Nov 2003 19:35:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26709; Sat, 15 Nov 2003 19:34:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAsd-0000hQ-00; Sat, 15 Nov 2003 19:35:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALAsc-0000hN-00; Sat, 15 Nov 2003 19:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAsX-0002Qq-I2; Sat, 15 Nov 2003 19:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAs7-0002Q1-Dp for simple@optimus.ietf.org; Sat, 15 Nov 2003 19:34:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26690 for ; Sat, 15 Nov 2003 19:34:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAs5-0000gc-00 for simple@ietf.org; Sat, 15 Nov 2003 19:34:33 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAs4-0000gM-00 for simple@ietf.org; Sat, 15 Nov 2003 19:34:32 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Nov 2003 16:37:01 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAG0Y0tg014059; Sat, 15 Nov 2003 16:34:01 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-104.cisco.com [10.21.64.104]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ46747; Sat, 15 Nov 2003 16:33:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: Cullen Jennings To: Adam Roach , "'Aki Niemi'" , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865F0@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] IM and file transfer Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 15 Nov 2003 16:33:57 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/11/03 9:27 AM, "Adam Roach" wrote: > > Aki Niemi [mailto:aki.niemi@nokia.com] writes: > >> These are somewhat orthogonal aspects of a message session. It is >> probably useful to label a specific session as e.g., file-transfer > > Yes. You do this by using port 21. If you know a priori that all > you are going to do is transfer files, the IETF has already > defined a file transfer protocol. Yes, and FTP meets my end user to end user file transfer needs somewhat less well than IRC meets my IMPP needs. File transfer is a requirement for any viable modern IM application. FTP will still be used for places where it meets the needs. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 17 09:23:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12550; Mon, 17 Nov 2003 09:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkIP-000754-00; Mon, 17 Nov 2003 09:24:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALkIP-00074y-00; Mon, 17 Nov 2003 09:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkIL-0000OI-Dz; Mon, 17 Nov 2003 09:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkIF-0000O5-Ez for simple@optimus.ietf.org; Mon, 17 Nov 2003 09:23:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12543 for ; Mon, 17 Nov 2003 09:23:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkID-00074v-00 for simple@ietf.org; Mon, 17 Nov 2003 09:23:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALkID-00074r-00 for simple@ietf.org; Mon, 17 Nov 2003 09:23:53 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2003 06:26:42 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHENKtg006168; Mon, 17 Nov 2003 06:23:20 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEA53798; Mon, 17 Nov 2003 09:22:12 -0500 (EST) Message-ID: <3FB8D992.8080601@cisco.com> 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: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 09:22:10 -0500 Content-Transfer-Encoding: 7bit Cullen, I don't have any data of my own on this subject, but I hope you are right. It would be a lot simpler if we can continue to assume that the way you reestablish an MSRP session is via a reINVITE. The adequacy of that was under question if NATs regularly blow away connections. Paul Cullen Jennings wrote: > There was some assertion in the WG meeting that NATs arbitrarily kill TCP > connection and the connection needs to be set up again. I'm sure this has > happened with broken NATS but I do not feel it is widespread and don't think > we should specifically design for it. I do think we should design for > graceful failure or recover when things in the network fail but I don't > think there is a common case of TCP failing that involves NATs. If there > were, many things that do not automatically set up a new TCP connection, > like ssh for example, would be nearly unusable through these broken NATs. > > 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 exim@www1.ietf.org Mon Nov 17 09:24:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12574 for ; Mon, 17 Nov 2003 09:24:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkIR-0000P7-LQ for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 09:24:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHEO7qF001549 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 09:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkIR-0000Ou-I8 for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 09:24:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12550; Mon, 17 Nov 2003 09:23:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkIP-000754-00; Mon, 17 Nov 2003 09:24:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALkIP-00074y-00; Mon, 17 Nov 2003 09:24:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkIL-0000OI-Dz; Mon, 17 Nov 2003 09:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkIF-0000O5-Ez for simple@optimus.ietf.org; Mon, 17 Nov 2003 09:23:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12543 for ; Mon, 17 Nov 2003 09:23:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkID-00074v-00 for simple@ietf.org; Mon, 17 Nov 2003 09:23:53 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALkID-00074r-00 for simple@ietf.org; Mon, 17 Nov 2003 09:23:53 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2003 06:26:42 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAHENKtg006168; Mon, 17 Nov 2003 06:23:20 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEA53798; Mon, 17 Nov 2003 09:22:12 -0500 (EST) Message-ID: <3FB8D992.8080601@cisco.com> 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: Cullen Jennings CC: simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 09:22:10 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen, I don't have any data of my own on this subject, but I hope you are right. It would be a lot simpler if we can continue to assume that the way you reestablish an MSRP session is via a reINVITE. The adequacy of that was under question if NATs regularly blow away connections. Paul Cullen Jennings wrote: > There was some assertion in the WG meeting that NATs arbitrarily kill TCP > connection and the connection needs to be set up again. I'm sure this has > happened with broken NATS but I do not feel it is widespread and don't think > we should specifically design for it. I do think we should design for > graceful failure or recover when things in the network fail but I don't > think there is a common case of TCP failing that involves NATs. If there > were, many things that do not automatically set up a new TCP connection, > like ssh for example, would be nearly unusable through these broken NATs. > > 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-admin@ietf.org Mon Nov 17 13:55:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28104; Mon, 17 Nov 2003 13:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALoWm-0004Du-00; Mon, 17 Nov 2003 13:55:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALoWm-0004Dr-00; Mon, 17 Nov 2003 13:55:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoWd-000739-N5; Mon, 17 Nov 2003 13:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoW9-0006yJ-EQ for simple@optimus.ietf.org; Mon, 17 Nov 2003 13:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28055 for ; Mon, 17 Nov 2003 13:54:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALoW7-0004DC-00 for simple@ietf.org; Mon, 17 Nov 2003 13:54:31 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ALoW6-0004Ch-00 for simple@ietf.org; Mon, 17 Nov 2003 13:54:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAHIrpd21366 for ; Mon, 17 Nov 2003 12:53:51 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1069095228.1150.44.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] ANNOUNCEMENT: Change of chairs Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 12:53:49 -0600 Content-Transfer-Encoding: 7bit Greetings all - I am happy to announce that Hisham Khartabil is joining me as a chair of the SIMPLE working group. Jon Peterson is stepping out of his SIMPLE chair role to focus on his responsibilities as an Area Director. He will, however, remain active in the group and will serve as a Technical Advisor for us. Please join me in extending thanks to both Hisham and Jon for helping us get SIMPLE's work done! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 17 13:55:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28145 for ; Mon, 17 Nov 2003 13:55:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoWp-00074D-I8 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 13:55:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHItFpc027159 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 13:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoWp-00073y-Dr for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 13:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28104; Mon, 17 Nov 2003 13:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALoWm-0004Du-00; Mon, 17 Nov 2003 13:55:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALoWm-0004Dr-00; Mon, 17 Nov 2003 13:55:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoWd-000739-N5; Mon, 17 Nov 2003 13:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALoW9-0006yJ-EQ for simple@optimus.ietf.org; Mon, 17 Nov 2003 13:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28055 for ; Mon, 17 Nov 2003 13:54:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALoW7-0004DC-00 for simple@ietf.org; Mon, 17 Nov 2003 13:54:31 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ALoW6-0004Ch-00 for simple@ietf.org; Mon, 17 Nov 2003 13:54:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAHIrpd21366 for ; Mon, 17 Nov 2003 12:53:51 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1069095228.1150.44.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] ANNOUNCEMENT: Change of chairs Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 12:53:49 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings all - I am happy to announce that Hisham Khartabil is joining me as a chair of the SIMPLE working group. Jon Peterson is stepping out of his SIMPLE chair role to focus on his responsibilities as an Area Director. He will, however, remain active in the group and will serve as a Technical Advisor for us. Please join me in extending thanks to both Hisham and Jon for helping us get SIMPLE's work done! RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 17 14:42:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29966; Mon, 17 Nov 2003 14:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpH6-0004u5-00; Mon, 17 Nov 2003 14:43:04 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ALpH5-0004tM-00; Mon, 17 Nov 2003 14:43:03 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ALpDG-0002ir-DE; Mon, 17 Nov 2003 14:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpDB-0000q8-8p; Mon, 17 Nov 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpCr-0000oT-LG for simple@optimus.ietf.org; Mon, 17 Nov 2003 14:38:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29753 for ; Mon, 17 Nov 2003 14:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpCo-0004qZ-00 for simple@ietf.org; Mon, 17 Nov 2003 14:38:38 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALpCn-0004qV-00 for simple@ietf.org; Mon, 17 Nov 2003 14:38:38 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHJbenG036973; Mon, 17 Nov 2003 13:37:46 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB92381.4050007@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> In-Reply-To: <3FB8D992.8080601@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 13:37:37 -0600 Content-Transfer-Encoding: 7bit I have personally encountered this behavior in the wild. I agree, however, that it was broken, and probably not a normal use case. And as far as I know, it pretty much killed anything other than hit-and-run HTTP connections. Paul Kyzivat wrote: > Cullen, > > I don't have any data of my own on this subject, but I hope you are right. > > It would be a lot simpler if we can continue to assume that the way you > reestablish an MSRP session is via a reINVITE. The adequacy of that was > under question if NATs regularly blow away connections. > > Paul > > Cullen Jennings wrote: > >> There was some assertion in the WG meeting that NATs arbitrarily kill TCP >> connection and the connection needs to be set up again. I'm sure this has >> happened with broken NATS but I do not feel it is widespread and don't >> think >> we should specifically design for it. I do think we should design for >> graceful failure or recover when things in the network fail but I don't >> think there is a common case of TCP failing that involves NATs. If there >> were, many things that do not automatically set up a new TCP connection, >> like ssh for example, would be nearly unusable through these broken NATs. >> >> 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 exim@www1.ietf.org Mon Nov 17 14:43:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00058 for ; Mon, 17 Nov 2003 14:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpH9-000176-Mi for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 14:43:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHJh7Ft004274 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 14:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpH9-00016r-Jf for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 14:43:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29966; Mon, 17 Nov 2003 14:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpH6-0004u5-00; Mon, 17 Nov 2003 14:43:04 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ALpH5-0004tM-00; Mon, 17 Nov 2003 14:43:03 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1ALpDG-0002ir-DE; Mon, 17 Nov 2003 14:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpDB-0000q8-8p; Mon, 17 Nov 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpCr-0000oT-LG for simple@optimus.ietf.org; Mon, 17 Nov 2003 14:38:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29753 for ; Mon, 17 Nov 2003 14:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpCo-0004qZ-00 for simple@ietf.org; Mon, 17 Nov 2003 14:38:38 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALpCn-0004qV-00 for simple@ietf.org; Mon, 17 Nov 2003 14:38:38 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHJbenG036973; Mon, 17 Nov 2003 13:37:46 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB92381.4050007@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> In-Reply-To: <3FB8D992.8080601@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 13:37:37 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have personally encountered this behavior in the wild. I agree, however, that it was broken, and probably not a normal use case. And as far as I know, it pretty much killed anything other than hit-and-run HTTP connections. Paul Kyzivat wrote: > Cullen, > > I don't have any data of my own on this subject, but I hope you are right. > > It would be a lot simpler if we can continue to assume that the way you > reestablish an MSRP session is via a reINVITE. The adequacy of that was > under question if NATs regularly blow away connections. > > Paul > > Cullen Jennings wrote: > >> There was some assertion in the WG meeting that NATs arbitrarily kill TCP >> connection and the connection needs to be set up again. I'm sure this has >> happened with broken NATS but I do not feel it is widespread and don't >> think >> we should specifically design for it. I do think we should design for >> graceful failure or recover when things in the network fail but I don't >> think there is a common case of TCP failing that involves NATs. If there >> were, many things that do not automatically set up a new TCP connection, >> like ssh for example, would be nearly unusable through these broken NATs. >> >> 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-admin@ietf.org Mon Nov 17 14:46:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00536; Mon, 17 Nov 2003 14:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpKv-00053i-00; Mon, 17 Nov 2003 14:47:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpKv-00053f-00; Mon, 17 Nov 2003 14:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpKv-0001cU-TJ; Mon, 17 Nov 2003 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpKG-0001as-B3 for simple@optimus.ietf.org; Mon, 17 Nov 2003 14:46:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00380 for ; Mon, 17 Nov 2003 14:46:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpKD-000526-00 for simple@ietf.org; Mon, 17 Nov 2003 14:46:17 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALpKC-00051h-00 for simple@ietf.org; Mon, 17 Nov 2003 14:46:16 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHJjxnG037727; Mon, 17 Nov 2003 13:45:59 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB92574.60407@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , "'Aki Niemi'" , simple@ietf.org Subject: Re: [Simple] IM and file transfer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 13:45:56 -0600 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/11/03 9:27 AM, "Adam Roach" wrote: > > >>Aki Niemi [mailto:aki.niemi@nokia.com] writes: >> >> >>>These are somewhat orthogonal aspects of a message session. It is >>>probably useful to label a specific session as e.g., file-transfer >> >>Yes. You do this by using port 21. If you know a priori that all >>you are going to do is transfer files, the IETF has already >>defined a file transfer protocol. > > > Yes, and FTP meets my end user to end user file transfer needs somewhat less > well than IRC meets my IMPP needs. File transfer is a requirement for any > viable modern IM application. FTP will still be used for places where it > meets the needs. I agree that it is a requirement for any modern application. That does not necessarily make it a requirement of a particular protocol. I know that under certain conditions, the mechanism yahoo uses for file transfer is very different than the mechanism it uses for IM transport. It would be well within reason for us to specify how to securly signal ftp sessions via SIP. That all being said, we established a consensus that MSRP (Or should that be MSP now?) was expected to be able to carry arbitrarily large content. I very much doubt that consensus has changed. > > 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 exim@www1.ietf.org Mon Nov 17 14:47:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00584 for ; Mon, 17 Nov 2003 14:47:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpKz-0001ey-By for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 14:47:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHJl5vZ006374 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 14:47:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpKz-0001ej-8e for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 14:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00536; Mon, 17 Nov 2003 14:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpKv-00053i-00; Mon, 17 Nov 2003 14:47:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALpKv-00053f-00; Mon, 17 Nov 2003 14:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpKv-0001cU-TJ; Mon, 17 Nov 2003 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALpKG-0001as-B3 for simple@optimus.ietf.org; Mon, 17 Nov 2003 14:46:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00380 for ; Mon, 17 Nov 2003 14:46:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALpKD-000526-00 for simple@ietf.org; Mon, 17 Nov 2003 14:46:17 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALpKC-00051h-00 for simple@ietf.org; Mon, 17 Nov 2003 14:46:16 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHJjxnG037727; Mon, 17 Nov 2003 13:45:59 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB92574.60407@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , "'Aki Niemi'" , simple@ietf.org Subject: Re: [Simple] IM and file transfer References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 13:45:56 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/11/03 9:27 AM, "Adam Roach" wrote: > > >>Aki Niemi [mailto:aki.niemi@nokia.com] writes: >> >> >>>These are somewhat orthogonal aspects of a message session. It is >>>probably useful to label a specific session as e.g., file-transfer >> >>Yes. You do this by using port 21. If you know a priori that all >>you are going to do is transfer files, the IETF has already >>defined a file transfer protocol. > > > Yes, and FTP meets my end user to end user file transfer needs somewhat less > well than IRC meets my IMPP needs. File transfer is a requirement for any > viable modern IM application. FTP will still be used for places where it > meets the needs. I agree that it is a requirement for any modern application. That does not necessarily make it a requirement of a particular protocol. I know that under certain conditions, the mechanism yahoo uses for file transfer is very different than the mechanism it uses for IM transport. It would be well within reason for us to specify how to securly signal ftp sessions via SIP. That all being said, we established a consensus that MSRP (Or should that be MSP now?) was expected to be able to carry arbitrarily large content. I very much doubt that consensus has changed. > > 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-admin@ietf.org Mon Nov 17 16:37:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06888; Mon, 17 Nov 2003 16:37:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr4T-0006mT-00; Mon, 17 Nov 2003 16:38:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALr4S-0006mQ-00; Mon, 17 Nov 2003 16:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr4L-0007if-QS; Mon, 17 Nov 2003 16:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKL6b-0005um-O5 for simple@optimus.ietf.org; Thu, 13 Nov 2003 12:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08863 for ; Thu, 13 Nov 2003 12:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKL6X-0001Fb-00 for simple@ietf.org; Thu, 13 Nov 2003 12:18:01 -0500 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 1AKL6X-0001FY-00 for simple@ietf.org; Thu, 13 Nov 2003 12:18:01 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AKL6V-00040E-00 for simple@ietf.org; Thu, 13 Nov 2003 17:17:59 +0000 Received: from [130.129.128.130] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AKL6V-000403-00 for simple@ietf.org; Thu, 13 Nov 2003 17:17:59 +0000 From: "Lisa Dusseault" To: Message-ID: <010601c3aa1a$cd627800$82808182@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Envelope-To: simple@ietf.org Content-Transfer-Encoding: quoted-printable Subject: [Simple] Pointer to draft-dusseault-http-patch-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 11:17:38 -0800 Content-Transfer-Encoding: quoted-printable This is the draft I just discussed in the SIMPLE WG meeting. I have = submitted=20 it to the IETF but here's another link: http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-= 00.txt This is a proposal to add a small feature to HTTP 1.1. In this proposal - The server may advertise support for some patch or diff file formats - The client can send a PATCH request to an *existing* HTTP 1.1 = resource - The PATCH request contains the patch or diff file to apply to the = resource - If the server can successfully apply the patch, it modifies the = resource - Various error codes are defined for invalid patches, invalid results, = etc Here's the example I put up on the screen in SIMPLE. The request line = and=20 headers are as required by the proposal. The body, however, is a vague = made-up example (without correct use of namespaces) which is intended to suggest = how an undefined XML patch format might work. (An XML patch format would be = defined in a separate document.) The example is intended to illustrate a possible use case for SIMPLE. PATCH /lisa/buddies.xml HTTP/1.1 Host: im.example.com Content-type: text/xcap+xml If-Match: "e0023aa4e" Content-Length: 100 presence-lists/list[@name=3D"friends"]/list[@name=3D"close-friends"] = Joe Smith=20 =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 17 16:38:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06913 for ; Mon, 17 Nov 2003 16:38:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr4W-0007nM-7U for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 16:38:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLcC9N029961 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 16:38:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr4V-0007m7-Lc for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 16:38:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06888; Mon, 17 Nov 2003 16:37:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALr4T-0006mT-00; Mon, 17 Nov 2003 16:38:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALr4S-0006mQ-00; Mon, 17 Nov 2003 16:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALr4L-0007if-QS; Mon, 17 Nov 2003 16:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKL6b-0005um-O5 for simple@optimus.ietf.org; Thu, 13 Nov 2003 12:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08863 for ; Thu, 13 Nov 2003 12:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKL6X-0001Fb-00 for simple@ietf.org; Thu, 13 Nov 2003 12:18:01 -0500 Received: from [206.14.210.116] (helo=mail.xythos.com) by ietf-mx with esmtp (Exim 4.12) id 1AKL6X-0001FY-00 for simple@ietf.org; Thu, 13 Nov 2003 12:18:01 -0500 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 1AKL6V-00040E-00 for simple@ietf.org; Thu, 13 Nov 2003 17:17:59 +0000 Received: from [130.129.128.130] (helo=lisalap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 1AKL6V-000403-00 for simple@ietf.org; Thu, 13 Nov 2003 17:17:59 +0000 From: "Lisa Dusseault" To: Message-ID: <010601c3aa1a$cd627800$82808182@lisalap> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Envelope-To: simple@ietf.org Content-Transfer-Encoding: quoted-printable Subject: [Simple] Pointer to draft-dusseault-http-patch-00.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 13 Nov 2003 11:17:38 -0800 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is the draft I just discussed in the SIMPLE WG meeting. I have = submitted=20 it to the IETF but here's another link: http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-= 00.txt This is a proposal to add a small feature to HTTP 1.1. In this proposal - The server may advertise support for some patch or diff file formats - The client can send a PATCH request to an *existing* HTTP 1.1 = resource - The PATCH request contains the patch or diff file to apply to the = resource - If the server can successfully apply the patch, it modifies the = resource - Various error codes are defined for invalid patches, invalid results, = etc Here's the example I put up on the screen in SIMPLE. The request line = and=20 headers are as required by the proposal. The body, however, is a vague = made-up example (without correct use of namespaces) which is intended to suggest = how an undefined XML patch format might work. (An XML patch format would be = defined in a separate document.) The example is intended to illustrate a possible use case for SIMPLE. PATCH /lisa/buddies.xml HTTP/1.1 Host: im.example.com Content-type: text/xcap+xml If-Match: "e0023aa4e" Content-Length: 100 presence-lists/list[@name=3D"friends"]/list[@name=3D"close-friends"] = Joe Smith=20 =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 17 16:44:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07299; Mon, 17 Nov 2003 16:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrBA-0006ty-00; Mon, 17 Nov 2003 16:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrBA-0006ts-00; Mon, 17 Nov 2003 16:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrB7-0000CV-IH; Mon, 17 Nov 2003 16:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrAD-0008TQ-5J for simple@optimus.ietf.org; Mon, 17 Nov 2003 16:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07225 for ; Mon, 17 Nov 2003 16:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrAB-0006sw-00 for simple@ietf.org; Mon, 17 Nov 2003 16:44:03 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALrA9-0006sl-00 for simple@ietf.org; Mon, 17 Nov 2003 16:44:02 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHLhbnG049388; Mon, 17 Nov 2003 15:43:44 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB94106.2020008@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E86605@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86605@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 15:43:34 -0600 Content-Transfer-Encoding: 7bit Adam Roach wrote: > Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > > >>[U]nless there is an agreement on how to standardize >>servers (by name or whatever), there isn't really much need to >>standardize *anything* about this behavior - even the name of the >>parameter (list=). It perhaps just becomes some sort of best >>practices or informational draft. > > > I came to the same conclusion. I think I like that fact. > I don't think this affects the need for standardization one way or another. We can standardize that the R-URI designates the application receiving the request, and leave the rest open. But we could also decide that a particular application (e.g. subscribing to an add-hoc list) is sufficiently interesting when interoperable to standardize that application. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 17 16:45:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07341 for ; Mon, 17 Nov 2003 16:45:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrBD-0000Ee-E3 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 16:45:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLj7lE000898 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 16:45:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrBD-0000EP-9W for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 16:45:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07299; Mon, 17 Nov 2003 16:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrBA-0006ty-00; Mon, 17 Nov 2003 16:45:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrBA-0006ts-00; Mon, 17 Nov 2003 16:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrB7-0000CV-IH; Mon, 17 Nov 2003 16:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrAD-0008TQ-5J for simple@optimus.ietf.org; Mon, 17 Nov 2003 16:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07225 for ; Mon, 17 Nov 2003 16:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrAB-0006sw-00 for simple@ietf.org; Mon, 17 Nov 2003 16:44:03 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALrA9-0006sl-00 for simple@ietf.org; Mon, 17 Nov 2003 16:44:02 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHLhbnG049388; Mon, 17 Nov 2003 15:43:44 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB94106.2020008@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E86605@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86605@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 15:43:34 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > > >>[U]nless there is an agreement on how to standardize >>servers (by name or whatever), there isn't really much need to >>standardize *anything* about this behavior - even the name of the >>parameter (list=). It perhaps just becomes some sort of best >>practices or informational draft. > > > I came to the same conclusion. I think I like that fact. > I don't think this affects the need for standardization one way or another. We can standardize that the R-URI designates the application receiving the request, and leave the rest open. But we could also decide that a particular application (e.g. subscribing to an add-hoc list) is sufficiently interesting when interoperable to standardize that application. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 17 17:05:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08659; Mon, 17 Nov 2003 17:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrVU-0007SF-00; Mon, 17 Nov 2003 17:06:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrVU-0007SC-00; Mon, 17 Nov 2003 17:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrVR-0001XW-Ma; Mon, 17 Nov 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrUY-0001GA-4A for simple@optimus.ietf.org; Mon, 17 Nov 2003 17:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08578 for ; Mon, 17 Nov 2003 17:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrUV-0007QA-00 for simple@ietf.org; Mon, 17 Nov 2003 17:05:03 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALrUV-0007Q7-00 for simple@ietf.org; Mon, 17 Nov 2003 17:05:03 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHM4unG051530 for ; Mon, 17 Nov 2003 16:05:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB94605.6020501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 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 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Open Issues Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 16:04:53 -0600 Content-Transfer-Encoding: 7bit Here is the list of significant issues and to-do's from the IETF58 meeting. At least, it is the list that I am aware of. Please send me anything I may have missed. (Numbers are for naming purposes, and do not indicate priority--with the exception of 1, of course. 3 Also seems high priority due to the number of items that depend on it) I plan to have a new rev of the base spec out before the end of December. That rev will include the removal of relays, and the other issues that we have closure on. Items that require more discussion will depend on the status of the discussion. ------------------------------------------------- 1. Remove relays from the base spec. (Saving relay text for relay specific work, of course...) Does this mean that we have to rename the protocol? 2. Remove text suggesting re-sending failed messages on the same connection. Instead, we should close the connection and re-connect. (See item 3...) 3. Close on handling of broken TCP connection. We discussed in the meeting that we should be able to reconnect without having to re-signal. (I remember now that we had discussed this before, and had a good reason at that time _not_ to do this--I will attempt to further remember the details so we can decide what currently makes sense.) 3.5 Determine if we need explicity un-visit (interacts with 3.) 4. Do we need a cross-connection duplicate suggestion mechanism? I think we said yes, if the new connection is part of the same session as the old. (Needs further list discussion as it interacts with 3...) 5. Generalize MIME handling to include mime version and allow arbitrary MIME headers. 6. Add text specifying use of sdp send-only attributes to identify sessions intended for one-way delivery of large content. 7. Close on keep-alive handling--needs more list discussion. In particular, do keep-alives need to be bi-directional? 8. Add more verbiage in security considerations, particularly considering TLS certificate usage, self-signed certificates, and interactions between TLS and digest authentication. (Cullen volunteered to send text on TLS cert usage.) (This also interacts with 3.) 9. A number of nits and editorial fixes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 17 17:06:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08719 for ; Mon, 17 Nov 2003 17:06:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrVX-0001eH-Qs for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 17:06:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHM67qY006337 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 17:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrVX-0001e8-K6 for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 17:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08659; Mon, 17 Nov 2003 17:05:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrVU-0007SF-00; Mon, 17 Nov 2003 17:06:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALrVU-0007SC-00; Mon, 17 Nov 2003 17:06:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrVR-0001XW-Ma; Mon, 17 Nov 2003 17:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALrUY-0001GA-4A for simple@optimus.ietf.org; Mon, 17 Nov 2003 17:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08578 for ; Mon, 17 Nov 2003 17:04:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALrUV-0007QA-00 for simple@ietf.org; Mon, 17 Nov 2003 17:05:03 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALrUV-0007Q7-00 for simple@ietf.org; Mon, 17 Nov 2003 17:05:03 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAHM4unG051530 for ; Mon, 17 Nov 2003 16:05:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB94605.6020501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 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 Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP Open Issues Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 16:04:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is the list of significant issues and to-do's from the IETF58 meeting. At least, it is the list that I am aware of. Please send me anything I may have missed. (Numbers are for naming purposes, and do not indicate priority--with the exception of 1, of course. 3 Also seems high priority due to the number of items that depend on it) I plan to have a new rev of the base spec out before the end of December. That rev will include the removal of relays, and the other issues that we have closure on. Items that require more discussion will depend on the status of the discussion. ------------------------------------------------- 1. Remove relays from the base spec. (Saving relay text for relay specific work, of course...) Does this mean that we have to rename the protocol? 2. Remove text suggesting re-sending failed messages on the same connection. Instead, we should close the connection and re-connect. (See item 3...) 3. Close on handling of broken TCP connection. We discussed in the meeting that we should be able to reconnect without having to re-signal. (I remember now that we had discussed this before, and had a good reason at that time _not_ to do this--I will attempt to further remember the details so we can decide what currently makes sense.) 3.5 Determine if we need explicity un-visit (interacts with 3.) 4. Do we need a cross-connection duplicate suggestion mechanism? I think we said yes, if the new connection is part of the same session as the old. (Needs further list discussion as it interacts with 3...) 5. Generalize MIME handling to include mime version and allow arbitrary MIME headers. 6. Add text specifying use of sdp send-only attributes to identify sessions intended for one-way delivery of large content. 7. Close on keep-alive handling--needs more list discussion. In particular, do keep-alives need to be bi-directional? 8. Add more verbiage in security considerations, particularly considering TLS certificate usage, self-signed certificates, and interactions between TLS and digest authentication. (Cullen volunteered to send text on TLS cert usage.) (This also interacts with 3.) 9. A number of nits and editorial fixes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 17 19:57:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16318; Mon, 17 Nov 2003 19:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuBx-0002ch-00; Mon, 17 Nov 2003 19:58:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALuBx-0002ce-00; Mon, 17 Nov 2003 19:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuBs-0003i9-Tk; Mon, 17 Nov 2003 19:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuBa-0003hs-AM for simple@optimus.ietf.org; Mon, 17 Nov 2003 19:57:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16314 for ; Mon, 17 Nov 2003 19:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuBY-0002ca-00 for simple@ietf.org; Mon, 17 Nov 2003 19:57:40 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1ALuBX-0002cX-00 for simple@ietf.org; Mon, 17 Nov 2003 19:57:39 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAI0v19d012851; Mon, 17 Nov 2003 18:57:01 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 18:57:01 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 18:57:00 -0600 Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > Adam Roach wrote: > > > Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > > > > > >>[U]nless there is an agreement on how to standardize > >>servers (by name or whatever), there isn't really much need to > >>standardize *anything* about this behavior - even the name of the > >>parameter (list=). It perhaps just becomes some sort of best > >>practices or informational draft. > > > > > > I came to the same conclusion. I think I like that fact. > > > > I don't think this affects the need for standardization one way or > another. We can standardize that the R-URI designates the application > receiving the request, and leave the rest open. Isn't that precisely what RFC 3087 already says? > But we could also decide that a particular application (e.g. > subscribing to an add-hoc list) is sufficiently interesting when > interoperable to standardize that application. I could easily see a standards-track document that defines semantics for a "list" parameter on a SIP URI (i.e. it points to a URI that, when dereferenced, contains a list of recipients that the application being invoked knows how to handle). Would that accomplish what you want to do? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 17 19:58:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16339 for ; Mon, 17 Nov 2003 19:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuC0-0003j2-Cz for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 19:58:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI0w8Oj014314 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 19:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuC0-0003in-9Q for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 19:58:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16318; Mon, 17 Nov 2003 19:57:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuBx-0002ch-00; Mon, 17 Nov 2003 19:58:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALuBx-0002ce-00; Mon, 17 Nov 2003 19:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuBs-0003i9-Tk; Mon, 17 Nov 2003 19:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALuBa-0003hs-AM for simple@optimus.ietf.org; Mon, 17 Nov 2003 19:57:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16314 for ; Mon, 17 Nov 2003 19:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALuBY-0002ca-00 for simple@ietf.org; Mon, 17 Nov 2003 19:57:40 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1ALuBX-0002cX-00 for simple@ietf.org; Mon, 17 Nov 2003 19:57:39 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAI0v19d012851; Mon, 17 Nov 2003 18:57:01 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 18:57:01 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 18:57:00 -0600 Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > > Adam Roach wrote: > > > Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: > > > > > >>[U]nless there is an agreement on how to standardize > >>servers (by name or whatever), there isn't really much need to > >>standardize *anything* about this behavior - even the name of the > >>parameter (list=). It perhaps just becomes some sort of best > >>practices or informational draft. > > > > > > I came to the same conclusion. I think I like that fact. > > > > I don't think this affects the need for standardization one way or > another. We can standardize that the R-URI designates the application > receiving the request, and leave the rest open. Isn't that precisely what RFC 3087 already says? > But we could also decide that a particular application (e.g. > subscribing to an add-hoc list) is sufficiently interesting when > interoperable to standardize that application. I could easily see a standards-track document that defines semantics for a "list" parameter on a SIP URI (i.e. it points to a URI that, when dereferenced, contains a list of recipients that the application being invoked knows how to handle). Would that accomplish what you want to do? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 17 21:32:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19015; Mon, 17 Nov 2003 21:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvfu-0003og-00; Mon, 17 Nov 2003 21:33:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALvfu-0003od-00; Mon, 17 Nov 2003 21:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvfp-00006T-Ne; Mon, 17 Nov 2003 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvfS-0008Ts-4b for simple@optimus.ietf.org; Mon, 17 Nov 2003 21:32:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19002 for ; Mon, 17 Nov 2003 21:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvfP-0003oG-00 for simple@ietf.org; Mon, 17 Nov 2003 21:32:35 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALvfO-0003o9-00 for simple@ietf.org; Mon, 17 Nov 2003 21:32:34 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAI2VinG072878; Mon, 17 Nov 2003 20:31:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB9848B.7060109@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 20:31:39 -0600 Content-Transfer-Encoding: 7bit Adam Roach wrote: > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >>Adam Roach wrote: >> >> >>>Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>> >>> >>> >>>>[U]nless there is an agreement on how to standardize >>>>servers (by name or whatever), there isn't really much need to >>>>standardize *anything* about this behavior - even the name of the >>>>parameter (list=). It perhaps just becomes some sort of best >>>>practices or informational draft. >>> >>> >>>I came to the same conclusion. I think I like that fact. >>> >> >>I don't think this affects the need for standardization one way or >>another. We can standardize that the R-URI designates the application >>receiving the request, and leave the rest open. > > > Isn't that precisely what RFC 3087 already says? > > >>But we could also decide that a particular application (e.g. >>subscribing to an add-hoc list) is sufficiently interesting when >>interoperable to standardize that application. > > > I could easily see a standards-track document that defines > semantics for a "list" parameter on a SIP URI (i.e. it points > to a URI that, when dereferenced, contains a list of recipients > that the application being invoked knows how to handle). Would > that accomplish what you want to do? My point was not that we need to standardize anything. It was to say that deciding to structure things this way, and deciding if anything needs to be standardized, are mostly orthagonal decisions. It seemed like we were going down the path of saying that, if we make this decision, we don't have to standardize anything. If that is a true statement, then we probably didn't need to standardize anything before, either. I suspect I am stating something so obvious that the act of stating it causes confusion. Nevermind. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 17 21:33:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19033 for ; Mon, 17 Nov 2003 21:33:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvfy-0000C8-Bf for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 21:33:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI2XAdj000747 for simple-archive@odin.ietf.org; Mon, 17 Nov 2003 21:33:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvfy-0000By-8D for simple-web-archive@optimus.ietf.org; Mon, 17 Nov 2003 21:33:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19015; Mon, 17 Nov 2003 21:32:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvfu-0003og-00; Mon, 17 Nov 2003 21:33:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ALvfu-0003od-00; Mon, 17 Nov 2003 21:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvfp-00006T-Ne; Mon, 17 Nov 2003 21:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALvfS-0008Ts-4b for simple@optimus.ietf.org; Mon, 17 Nov 2003 21:32:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19002 for ; Mon, 17 Nov 2003 21:32:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALvfP-0003oG-00 for simple@ietf.org; Mon, 17 Nov 2003 21:32:35 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ALvfO-0003o9-00 for simple@ietf.org; Mon, 17 Nov 2003 21:32:34 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAI2VinG072878; Mon, 17 Nov 2003 20:31:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB9848B.7060109@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Paul Kyzivat'" , Markus.Isomaki@nokia.com, dean.willis@softarmor.com, Jonathan Rosenberg , simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions References: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 17 Nov 2003 20:31:39 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Adam Roach wrote: > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: > >>Adam Roach wrote: >> >> >>>Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>> >>> >>> >>>>[U]nless there is an agreement on how to standardize >>>>servers (by name or whatever), there isn't really much need to >>>>standardize *anything* about this behavior - even the name of the >>>>parameter (list=). It perhaps just becomes some sort of best >>>>practices or informational draft. >>> >>> >>>I came to the same conclusion. I think I like that fact. >>> >> >>I don't think this affects the need for standardization one way or >>another. We can standardize that the R-URI designates the application >>receiving the request, and leave the rest open. > > > Isn't that precisely what RFC 3087 already says? > > >>But we could also decide that a particular application (e.g. >>subscribing to an add-hoc list) is sufficiently interesting when >>interoperable to standardize that application. > > > I could easily see a standards-track document that defines > semantics for a "list" parameter on a SIP URI (i.e. it points > to a URI that, when dereferenced, contains a list of recipients > that the application being invoked knows how to handle). Would > that accomplish what you want to do? My point was not that we need to standardize anything. It was to say that deciding to structure things this way, and deciding if anything needs to be standardized, are mostly orthagonal decisions. It seemed like we were going down the path of saying that, if we make this decision, we don't have to standardize anything. If that is a true statement, then we probably didn't need to standardize anything before, either. I suspect I am stating something so obvious that the act of stating it causes confusion. Nevermind. > > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 04:30:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11682; Tue, 18 Nov 2003 04:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2CP-0001GB-00; Tue, 18 Nov 2003 04:31:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2CP-0001G8-00; Tue, 18 Nov 2003 04:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CO-0004NW-HM; Tue, 18 Nov 2003 04:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2Bi-0004Lk-Io for simple@optimus.ietf.org; Tue, 18 Nov 2003 04:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11644 for ; Tue, 18 Nov 2003 04:30:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Bf-0001FH-00 for simple@ietf.org; Tue, 18 Nov 2003 04:30:19 -0500 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Be-0001Et-00 for simple@ietf.org; Tue, 18 Nov 2003 04:30:18 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp3.clb.oleane.net with SMTP id hAI9TmTa000802 for ; Tue, 18 Nov 2003 10:29:48 +0100 Message-ID: <02ab01c3adb7$1da9e600$0601a8c0@www.oleane.com> From: "mwinkhler" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A8_01C3ADBF.7F1A61A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Simple] 2004 WiFi Voice Conference Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 10:34:07 +0100 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_02A8_01C3ADBF.7F1A61A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The 2004 WiFi Voice Conference will stand in Paris on May 25 to 28, = 2004.=20 The call for papers dead line has been extended until December 15, 2003. = Get more details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm We also remind you that registration is still open to the New Mobile = Technologies Forum (UWB, IPCN and IPv6 Mobile sessions) at: http://www.upperside.fr/newmobtech/newmobtech03intro.htm ------=_NextPart_000_02A8_01C3ADBF.7F1A61A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The 2004 WiFi Voice=20 Conference will stand in Paris on May 25 to=20 28, 2004. 
The call for papers dead line has been = extended until=20 December 15, 2003.
Get more details at:
http://= www.upperside.fr/wifivoice04/wifivoice04intro.htm
 
We also remind you that registration is still open to the New Mobile Technologies Forum (UWB, IPCN and IPv6 = Mobile=20 sessions) at:
http://= www.upperside.fr/newmobtech/newmobtech03intro.htm
<= /DIV>
 
 
------=_NextPart_000_02A8_01C3ADBF.7F1A61A0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 04:31:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11725 for ; Tue, 18 Nov 2003 04:31:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CT-0004Q6-Jd for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 04:31:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAI9V9Yp016991 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 04:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CT-0004Px-1o for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 04:31:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11682; Tue, 18 Nov 2003 04:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2CP-0001GB-00; Tue, 18 Nov 2003 04:31:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM2CP-0001G8-00; Tue, 18 Nov 2003 04:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2CO-0004NW-HM; Tue, 18 Nov 2003 04:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM2Bi-0004Lk-Io for simple@optimus.ietf.org; Tue, 18 Nov 2003 04:30:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11644 for ; Tue, 18 Nov 2003 04:30:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Bf-0001FH-00 for simple@ietf.org; Tue, 18 Nov 2003 04:30:19 -0500 Received: from smtp3.clb.oleane.net ([213.56.31.19]) by ietf-mx with esmtp (Exim 4.12) id 1AM2Be-0001Et-00 for simple@ietf.org; Tue, 18 Nov 2003 04:30:18 -0500 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp3.clb.oleane.net with SMTP id hAI9TmTa000802 for ; Tue, 18 Nov 2003 10:29:48 +0100 Message-ID: <02ab01c3adb7$1da9e600$0601a8c0@www.oleane.com> From: "mwinkhler" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A8_01C3ADBF.7F1A61A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [Simple] 2004 WiFi Voice Conference Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 10:34:07 +0100 C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_02A8_01C3ADBF.7F1A61A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The 2004 WiFi Voice Conference will stand in Paris on May 25 to 28, = 2004.=20 The call for papers dead line has been extended until December 15, 2003. = Get more details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm We also remind you that registration is still open to the New Mobile = Technologies Forum (UWB, IPCN and IPv6 Mobile sessions) at: http://www.upperside.fr/newmobtech/newmobtech03intro.htm ------=_NextPart_000_02A8_01C3ADBF.7F1A61A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The 2004 WiFi Voice=20 Conference will stand in Paris on May 25 to=20 28, 2004. 
The call for papers dead line has been = extended until=20 December 15, 2003.
Get more details at:
http://= www.upperside.fr/wifivoice04/wifivoice04intro.htm
 
We also remind you that registration is still open to the New Mobile Technologies Forum (UWB, IPCN and IPv6 = Mobile=20 sessions) at:
http://= www.upperside.fr/newmobtech/newmobtech03intro.htm
<= /DIV>
 
 
------=_NextPart_000_02A8_01C3ADBF.7F1A61A0-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 09:56:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23143; Tue, 18 Nov 2003 09:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7Ht-0006Ly-00; Tue, 18 Nov 2003 09:57:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM7Ht-0006Lt-00; Tue, 18 Nov 2003 09:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Hp-0000Wn-2M; Tue, 18 Nov 2003 09:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7H5-0000WL-Qr for simple@optimus.ietf.org; Tue, 18 Nov 2003 09:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23130 for ; Tue, 18 Nov 2003 09:56:03 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7H3-0006L5-00 for simple@ietf.org; Tue, 18 Nov 2003 09:56:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AM7H3-0006L2-00 for simple@ietf.org; Tue, 18 Nov 2003 09:56:13 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAIEuCA02688 for ; Tue, 18 Nov 2003 16:56:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Nov 2003 16:56:09 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Nov 2003 16:56:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] MSRP Open Issues Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Open Issues Thread-Index: AcOtVwkJujsCDL8EQ9WAHq2HvrCAOQAWb6Yg To: , X-OriginalArrivalTime: 18 Nov 2003 14:56:09.0001 (UTC) FILETIME=[19977190:01C3ADE4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 16:56:08 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: Tuesday, November 18, 2003 12:05 AM > To: Simple WG > Subject: [Simple] MSRP Open Issues >=20 >=20 > Here is the list of significant issues and to-do's from the IETF58=20 > meeting. At least, it is the list that I am aware of. Please send me=20 > anything I may have missed. (Numbers are for naming purposes,=20 > and do not=20 > indicate priority--with the exception of 1, of course. 3 Also=20 > seems high=20 > priority due to the number of items that depend on it) >=20 > I plan to have a new rev of the base spec out before the end of=20 > December. That rev will include the removal of relays, and the other=20 > issues that we have closure on. Items that require more=20 > discussion will=20 > depend on the status of the discussion. >=20 > ------------------------------------------------- > 1. Remove relays from the base spec. (Saving relay text for relay=20 > specific work, of course...) Does this mean that we have to=20 > rename the=20 > protocol? MSP is ok. >=20 > 2. Remove text suggesting re-sending failed messages on the same=20 > connection. Instead, we should close the connection and=20 > re-connect. (See=20 > item 3...) I'm still confused about this one. Long messages might cause a time-out = at the sender's side. Perhaps we need to define 3 different behaviours: a) a timeout b) an error response c) broken TCP connection a) is what I have real concern for when long messages are involved. Is = the problem gone when relays are removed? >=20 > 3. Close on handling of broken TCP connection. We discussed in the=20 > meeting that we should be able to reconnect without having to=20 > re-signal.=20 > (I remember now that we had discussed this before, and had a=20 > good reason=20 > at that time _not_ to do this--I will attempt to further remember the=20 > details so we can decide what currently makes sense.) One endpoint might crash and reboot. Ports might change so you need to = re-signal. >=20 > 3.5 Determine if we need explicity un-visit (interacts with 3.) I think its needed. If the visitor just tears down the TCP connection, = the host does not know if the visitor deliberately ended the session, or = if something has gone wrong at the visitor side. >=20 > 4. Do we need a cross-connection duplicate suggestion=20 > mechanism? I think=20 > we said yes, if the new connection is part of the same session as the=20 > old. (Needs further list discussion as it interacts with 3...) Now you are calling sessions connections? I still think retransmission = is not needed. >=20 > 5. Generalize MIME handling to include mime version and allow=20 > arbitrary=20 > MIME headers. >=20 > 6. Add text specifying use of sdp send-only attributes to identify=20 > sessions intended for one-way delivery of large content. >=20 > 7. Close on keep-alive handling--needs more list discussion. In=20 > particular, do keep-alives need to be bi-directional? Probably not. a keep-alive from one side results in a 200 from the = other. Therefore both sides are alive. >=20 > 8. Add more verbiage in security considerations, particularly=20 > considering TLS certificate usage, self-signed certificates, and=20 > interactions between TLS and digest authentication. (Cullen=20 > volunteered=20 > to send text on TLS cert usage.) (This also interacts with 3.) >=20 > 9. A number of nits and editorial fixes. 10. We need normative text about how to construct a second SDP = offer/answer exchange. Regards, Hisham >=20 >=20 >=20 >=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 exim@www1.ietf.org Tue Nov 18 09:57:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23159 for ; Tue, 18 Nov 2003 09:57:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Hw-0000Y1-IJ for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 09:57:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIEv8nc002099 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 09:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Hw-0000Xm-Eq for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 09:57:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23143; Tue, 18 Nov 2003 09:56:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7Ht-0006Ly-00; Tue, 18 Nov 2003 09:57:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM7Ht-0006Lt-00; Tue, 18 Nov 2003 09:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Hp-0000Wn-2M; Tue, 18 Nov 2003 09:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7H5-0000WL-Qr for simple@optimus.ietf.org; Tue, 18 Nov 2003 09:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23130 for ; Tue, 18 Nov 2003 09:56:03 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7H3-0006L5-00 for simple@ietf.org; Tue, 18 Nov 2003 09:56:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AM7H3-0006L2-00 for simple@ietf.org; Tue, 18 Nov 2003 09:56:13 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAIEuCA02688 for ; Tue, 18 Nov 2003 16:56:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 18 Nov 2003 16:56:09 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 18 Nov 2003 16:56:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] MSRP Open Issues Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP Open Issues Thread-Index: AcOtVwkJujsCDL8EQ9WAHq2HvrCAOQAWb6Yg To: , X-OriginalArrivalTime: 18 Nov 2003 14:56:09.0001 (UTC) FILETIME=[19977190:01C3ADE4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 16:56:08 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: Tuesday, November 18, 2003 12:05 AM > To: Simple WG > Subject: [Simple] MSRP Open Issues >=20 >=20 > Here is the list of significant issues and to-do's from the IETF58=20 > meeting. At least, it is the list that I am aware of. Please send me=20 > anything I may have missed. (Numbers are for naming purposes,=20 > and do not=20 > indicate priority--with the exception of 1, of course. 3 Also=20 > seems high=20 > priority due to the number of items that depend on it) >=20 > I plan to have a new rev of the base spec out before the end of=20 > December. That rev will include the removal of relays, and the other=20 > issues that we have closure on. Items that require more=20 > discussion will=20 > depend on the status of the discussion. >=20 > ------------------------------------------------- > 1. Remove relays from the base spec. (Saving relay text for relay=20 > specific work, of course...) Does this mean that we have to=20 > rename the=20 > protocol? MSP is ok. >=20 > 2. Remove text suggesting re-sending failed messages on the same=20 > connection. Instead, we should close the connection and=20 > re-connect. (See=20 > item 3...) I'm still confused about this one. Long messages might cause a time-out = at the sender's side. Perhaps we need to define 3 different behaviours: a) a timeout b) an error response c) broken TCP connection a) is what I have real concern for when long messages are involved. Is = the problem gone when relays are removed? >=20 > 3. Close on handling of broken TCP connection. We discussed in the=20 > meeting that we should be able to reconnect without having to=20 > re-signal.=20 > (I remember now that we had discussed this before, and had a=20 > good reason=20 > at that time _not_ to do this--I will attempt to further remember the=20 > details so we can decide what currently makes sense.) One endpoint might crash and reboot. Ports might change so you need to = re-signal. >=20 > 3.5 Determine if we need explicity un-visit (interacts with 3.) I think its needed. If the visitor just tears down the TCP connection, = the host does not know if the visitor deliberately ended the session, or = if something has gone wrong at the visitor side. >=20 > 4. Do we need a cross-connection duplicate suggestion=20 > mechanism? I think=20 > we said yes, if the new connection is part of the same session as the=20 > old. (Needs further list discussion as it interacts with 3...) Now you are calling sessions connections? I still think retransmission = is not needed. >=20 > 5. Generalize MIME handling to include mime version and allow=20 > arbitrary=20 > MIME headers. >=20 > 6. Add text specifying use of sdp send-only attributes to identify=20 > sessions intended for one-way delivery of large content. >=20 > 7. Close on keep-alive handling--needs more list discussion. In=20 > particular, do keep-alives need to be bi-directional? Probably not. a keep-alive from one side results in a 200 from the = other. Therefore both sides are alive. >=20 > 8. Add more verbiage in security considerations, particularly=20 > considering TLS certificate usage, self-signed certificates, and=20 > interactions between TLS and digest authentication. (Cullen=20 > volunteered=20 > to send text on TLS cert usage.) (This also interacts with 3.) >=20 > 9. A number of nits and editorial fixes. 10. We need normative text about how to construct a second SDP = offer/answer exchange. Regards, Hisham >=20 >=20 >=20 >=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-admin@ietf.org Tue Nov 18 10:15:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25140; Tue, 18 Nov 2003 10:15:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7aJ-0006hn-00; Tue, 18 Nov 2003 10:16:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM7aJ-0006hk-00; Tue, 18 Nov 2003 10:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7aE-0001fC-0S; Tue, 18 Nov 2003 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Zq-0001eN-GI for simple@optimus.ietf.org; Tue, 18 Nov 2003 10:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25091 for ; Tue, 18 Nov 2003 10:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7Zo-0006hZ-00 for simple@ietf.org; Tue, 18 Nov 2003 10:15:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AM7Zn-0006hV-00 for simple@ietf.org; Tue, 18 Nov 2003 10:15:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIFFEnG031365; Tue, 18 Nov 2003 09:15:25 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA377E.8070903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP Open Issues References: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 09:15:10 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: Tuesday, November 18, 2003 12:05 AM >>To: Simple WG >>Subject: [Simple] MSRP Open Issues >> >> >>Here is the list of significant issues and to-do's from the IETF58 >>meeting. At least, it is the list that I am aware of. Please send me >>anything I may have missed. (Numbers are for naming purposes, >>and do not >>indicate priority--with the exception of 1, of course. 3 Also >>seems high >>priority due to the number of items that depend on it) >> >>I plan to have a new rev of the base spec out before the end of >>December. That rev will include the removal of relays, and the other >>issues that we have closure on. Items that require more >>discussion will >>depend on the status of the discussion. >> >>------------------------------------------------- >>1. Remove relays from the base spec. (Saving relay text for relay >>specific work, of course...) Does this mean that we have to >>rename the >>protocol? > > > MSP is ok. > > >>2. Remove text suggesting re-sending failed messages on the same >>connection. Instead, we should close the connection and >>re-connect. (See >>item 3...) > > > I'm still confused about this one. Long messages might cause a time-out at the sender's side. Perhaps we need to define 3 different behaviours: > > a) a timeout > b) an error response > c) broken TCP connection > > a) is what I have real concern for when long messages are involved. Is the problem gone when relays are removed? I think the timeout problem goes away with no relays (Although we do want to make sure we do not paint ourselves into a corner where relays become impossible.) > > >>3. Close on handling of broken TCP connection. We discussed in the >>meeting that we should be able to reconnect without having to >>re-signal. >>(I remember now that we had discussed this before, and had a >>good reason >>at that time _not_ to do this--I will attempt to further remember the >>details so we can decide what currently makes sense.) > > > One endpoint might crash and reboot. Ports might change so you need to re-signal. > That is certainly a scenario where reconnecting would not work. I think, though, that we had come up with a reason why reconnecting was _never_ a good idea; I'm still trying to reconstitute the reasoning. > >>3.5 Determine if we need explicity un-visit (interacts with 3.) > > > I think its needed. If the visitor just tears down the TCP connection, the host does not know if the visitor deliberately ended the session, or if something has gone wrong at the visitor side. > I agree, _if_ we decide to change the specification so that a dropped connection no longer automatically destroys the session. > >>4. Do we need a cross-connection duplicate suggestion >>mechanism? I think >>we said yes, if the new connection is part of the same session as the >>old. (Needs further list discussion as it interacts with 3...) > > > Now you are calling sessions connections? I still think retransmission is not needed. I was talking about a situation where we lose a connection and reconnect as part of the same session, or a new session that is somehow correlated with the first session. This goes back to item 3. > > >>5. Generalize MIME handling to include mime version and allow >>arbitrary >>MIME headers. >> >>6. Add text specifying use of sdp send-only attributes to identify >>sessions intended for one-way delivery of large content. >> >>7. Close on keep-alive handling--needs more list discussion. In >>particular, do keep-alives need to be bi-directional? > > > Probably not. a keep-alive from one side results in a 200 from the other. Therefore both sides are alive. > > >>8. Add more verbiage in security considerations, particularly >>considering TLS certificate usage, self-signed certificates, and >>interactions between TLS and digest authentication. (Cullen >>volunteered >>to send text on TLS cert usage.) (This also interacts with 3.) >> >>9. A number of nits and editorial fixes. > > > 10. We need normative text about how to construct a second SDP offer/answer exchange. Yes, thank you. I will add that one. > > Regards, > Hisham > > >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 10:16:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25229 for ; Tue, 18 Nov 2003 10:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7aM-0001hF-QZ for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 10:16:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIFGA5S006515 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 10:16:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7aM-0001h0-MW for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 10:16:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25140; Tue, 18 Nov 2003 10:15:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7aJ-0006hn-00; Tue, 18 Nov 2003 10:16:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM7aJ-0006hk-00; Tue, 18 Nov 2003 10:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7aE-0001fC-0S; Tue, 18 Nov 2003 10:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM7Zq-0001eN-GI for simple@optimus.ietf.org; Tue, 18 Nov 2003 10:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25091 for ; Tue, 18 Nov 2003 10:15:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM7Zo-0006hZ-00 for simple@ietf.org; Tue, 18 Nov 2003 10:15:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AM7Zn-0006hV-00 for simple@ietf.org; Tue, 18 Nov 2003 10:15:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIFFEnG031365; Tue, 18 Nov 2003 09:15:25 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA377E.8070903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP Open Issues References: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 09:15:10 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: Tuesday, November 18, 2003 12:05 AM >>To: Simple WG >>Subject: [Simple] MSRP Open Issues >> >> >>Here is the list of significant issues and to-do's from the IETF58 >>meeting. At least, it is the list that I am aware of. Please send me >>anything I may have missed. (Numbers are for naming purposes, >>and do not >>indicate priority--with the exception of 1, of course. 3 Also >>seems high >>priority due to the number of items that depend on it) >> >>I plan to have a new rev of the base spec out before the end of >>December. That rev will include the removal of relays, and the other >>issues that we have closure on. Items that require more >>discussion will >>depend on the status of the discussion. >> >>------------------------------------------------- >>1. Remove relays from the base spec. (Saving relay text for relay >>specific work, of course...) Does this mean that we have to >>rename the >>protocol? > > > MSP is ok. > > >>2. Remove text suggesting re-sending failed messages on the same >>connection. Instead, we should close the connection and >>re-connect. (See >>item 3...) > > > I'm still confused about this one. Long messages might cause a time-out at the sender's side. Perhaps we need to define 3 different behaviours: > > a) a timeout > b) an error response > c) broken TCP connection > > a) is what I have real concern for when long messages are involved. Is the problem gone when relays are removed? I think the timeout problem goes away with no relays (Although we do want to make sure we do not paint ourselves into a corner where relays become impossible.) > > >>3. Close on handling of broken TCP connection. We discussed in the >>meeting that we should be able to reconnect without having to >>re-signal. >>(I remember now that we had discussed this before, and had a >>good reason >>at that time _not_ to do this--I will attempt to further remember the >>details so we can decide what currently makes sense.) > > > One endpoint might crash and reboot. Ports might change so you need to re-signal. > That is certainly a scenario where reconnecting would not work. I think, though, that we had come up with a reason why reconnecting was _never_ a good idea; I'm still trying to reconstitute the reasoning. > >>3.5 Determine if we need explicity un-visit (interacts with 3.) > > > I think its needed. If the visitor just tears down the TCP connection, the host does not know if the visitor deliberately ended the session, or if something has gone wrong at the visitor side. > I agree, _if_ we decide to change the specification so that a dropped connection no longer automatically destroys the session. > >>4. Do we need a cross-connection duplicate suggestion >>mechanism? I think >>we said yes, if the new connection is part of the same session as the >>old. (Needs further list discussion as it interacts with 3...) > > > Now you are calling sessions connections? I still think retransmission is not needed. I was talking about a situation where we lose a connection and reconnect as part of the same session, or a new session that is somehow correlated with the first session. This goes back to item 3. > > >>5. Generalize MIME handling to include mime version and allow >>arbitrary >>MIME headers. >> >>6. Add text specifying use of sdp send-only attributes to identify >>sessions intended for one-way delivery of large content. >> >>7. Close on keep-alive handling--needs more list discussion. In >>particular, do keep-alives need to be bi-directional? > > > Probably not. a keep-alive from one side results in a 200 from the other. Therefore both sides are alive. > > >>8. Add more verbiage in security considerations, particularly >>considering TLS certificate usage, self-signed certificates, and >>interactions between TLS and digest authentication. (Cullen >>volunteered >>to send text on TLS cert usage.) (This also interacts with 3.) >> >>9. A number of nits and editorial fixes. > > > 10. We need normative text about how to construct a second SDP offer/answer exchange. Yes, thank you. I will add that one. > > Regards, > Hisham > > >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 11:14:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27998; Tue, 18 Nov 2003 11:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8UX-0007jN-00; Tue, 18 Nov 2003 11:14:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM8UW-0007jJ-00; Tue, 18 Nov 2003 11:14:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8UL-0004u6-1E; Tue, 18 Nov 2003 11:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8Ty-0004t4-Ph for simple@optimus.ietf.org; Tue, 18 Nov 2003 11:13:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27962 for ; Tue, 18 Nov 2003 11:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8Tx-0007iZ-00 for simple@ietf.org; Tue, 18 Nov 2003 11:13:38 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AM8Tx-0007iR-00 for simple@ietf.org; Tue, 18 Nov 2003 11:13:37 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIGDWSs020702; Tue, 18 Nov 2003 17:13:32 +0100 (MET) Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.119]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NQ72PC; Tue, 18 Nov 2003 17:13:32 +0100 Message-ID: <3FBA452B.9070307@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP Open Issues References: <3FB94605.6020501@dynamicsoft.com> In-Reply-To: <3FB94605.6020501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 18:13:31 +0200 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > 5. Generalize MIME handling to include mime version and allow arbitrary > MIME headers. > Will this include the possibility of sending all the Content-* headers in MSRP. So far the draft only includes Content-Type, but I believe other Content-* headers will be useful (e.g., Content-Transfer-Encoding or Content-Disposition). /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 11:14:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28031 for ; Tue, 18 Nov 2003 11:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8UZ-0004v8-Lj for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 11:14:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGEF0u018908 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 11:14:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8UZ-0004ut-H3 for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 11:14:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27998; Tue, 18 Nov 2003 11:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8UX-0007jN-00; Tue, 18 Nov 2003 11:14:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM8UW-0007jJ-00; Tue, 18 Nov 2003 11:14:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8UL-0004u6-1E; Tue, 18 Nov 2003 11:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8Ty-0004t4-Ph for simple@optimus.ietf.org; Tue, 18 Nov 2003 11:13:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27962 for ; Tue, 18 Nov 2003 11:13:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8Tx-0007iZ-00 for simple@ietf.org; Tue, 18 Nov 2003 11:13:38 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AM8Tx-0007iR-00 for simple@ietf.org; Tue, 18 Nov 2003 11:13:37 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAIGDWSs020702; Tue, 18 Nov 2003 17:13:32 +0100 (MET) Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.119]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id V6NQ72PC; Tue, 18 Nov 2003 17:13:32 +0100 Message-ID: <3FBA452B.9070307@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP Open Issues References: <3FB94605.6020501@dynamicsoft.com> In-Reply-To: <3FB94605.6020501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 18:13:31 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > 5. Generalize MIME handling to include mime version and allow arbitrary > MIME headers. > Will this include the possibility of sending all the Content-* headers in MSRP. So far the draft only includes Content-Type, but I believe other Content-* headers will be useful (e.g., Content-Transfer-Encoding or Content-Disposition). /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 11:29:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28639; Tue, 18 Nov 2003 11:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8js-0000CF-00; Tue, 18 Nov 2003 11:30:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM8js-0000CC-00; Tue, 18 Nov 2003 11:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8jo-0005qn-Ue; Tue, 18 Nov 2003 11:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8jd-0005q0-Vq for simple@optimus.ietf.org; Tue, 18 Nov 2003 11:29:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28624 for ; Tue, 18 Nov 2003 11:29:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8jc-0000Bh-00 for simple@ietf.org; Tue, 18 Nov 2003 11:29:48 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AM8jb-0000B2-00 for simple@ietf.org; Tue, 18 Nov 2003 11:29:48 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 08:37:30 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAIGTDtg013945; Tue, 18 Nov 2003 08:29:14 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEB57055; Tue, 18 Nov 2003 11:29:13 -0500 (EST) Message-ID: <3FBA48D9.9050601@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP Open Issues References: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> <3FBA377E.8070903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 11:29:13 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > hisham.khartabil@nokia.com wrote: > >>> 2. Remove text suggesting re-sending failed messages on the same >>> connection. Instead, we should close the connection and re-connect. >>> (See item 3...) >> >> I'm still confused about this one. Long messages might cause a >> time-out at the sender's side. Perhaps we need to define 3 different >> behaviours: >> >> a) a timeout >> b) an error response >> c) broken TCP connection >> >> a) is what I have real concern for when long messages are involved. Is >> the problem gone when relays are removed? Even with relays, of the sort we were planning, timeouts shouldn't have been an issue any more than congestion in the network is. I don't think this has much to do with the size of the message - the timer isn't going to start until the last byte of the message is sent. As long as the connection is point to point or relays pass on data as they get it, there will typically only be a modest amount of data left to transit the connection when the last byte is sent. So the chance of timeout is the same as if the large preceding amount of data hadn't been sent. In fact it is probably less likely because a larger window will have been opened. Nevertheless, congestion could cause timeouts, and we ought to think about the proper recovery from them. The only ones I can think of that makes sense are to give up or eliminate the timeout. Note that this will perhaps get worse if we are going to try again to do a traffic multiplexing relay protocol. > I think the timeout problem goes away with no relays (Although we do > want to make sure we do not paint ourselves into a corner where relays > become impossible.) You can still get congestion, reducing the rate at which you can get data thru the connection. >>> 3. Close on handling of broken TCP connection. We discussed in the >>> meeting that we should be able to reconnect without having to >>> re-signal. (I remember now that we had discussed this before, and had >>> a good reason at that time _not_ to do this--I will attempt to >>> further remember the details so we can decide what currently makes >>> sense.) >> >> One endpoint might crash and reboot. Ports might change so you need to >> re-signal. > > That is certainly a scenario where reconnecting would not work. I think, > though, that we had come up with a reason why reconnecting was _never_ a > good idea; I'm still trying to reconstitute the reasoning. I can recall a couple: - one was a security issue - giving more opportunity for somebody else to try to break in. I'm not convinced this is a valid concern. - if you can reconnect at any time, the host must be listening for new connections all the time. If you say there can only be one, then as soon as that one is received then listening can stop. This is potentially significant. >>> 3.5 Determine if we need explicity un-visit (interacts with 3.) >> >> I think its needed. If the visitor just tears down the TCP connection, >> the host does not know if the visitor deliberately ended the session, >> or if something has gone wrong at the visitor side. > > I agree, _if_ we decide to change the specification so that a dropped > connection no longer automatically destroys the session. This ties in with the proceedure for gracefully closing a connection. The real question is whether you cna tell if the close was graceful without the un-visit. Maybe it is possible if there is signaling that announces the close, and both sides then drain data from the connection. >>> 4. Do we need a cross-connection duplicate suggestion mechanism? I >>> think we said yes, if the new connection is part of the same session >>> as the old. (Needs further list discussion as it interacts with 3...) duplicate *suggestion* mechanism??? I'm suggesting that duplicates be sent when failing over, but I don't require a special mechanism for making the suggestion. :-) (I suppose you mean duplicate *suppression* mechanism.) >> Now you are calling sessions connections? I still think retransmission >> is not needed. I think perhaps we lack the proper vocabulary here. Since SIP is the *session* initiation protocol, and SDP is the *session* description protocol, I believe we must believe that the thing established by an offer/answer exchange of m-lines is a session. In this case we use a TCP connection to implement the session. The case in question is where an offer/answer exchange within a call establishes an MSRP session. Then later, in the same call, another offer/answer exchange establishes a different MSRP session that logically replaces the previous one. Is there some term that describes the concatenation of those two MSRP sessions? I don't think there is, but we need one. It is a bit like "conversation space" as specified in draft-ietf-sipping-cc-framework-03. When there is trouble sending a message over an MSRP session and recovery is attempted by replacing the MSRP session with another in the same conversation space where retransmission of the failed message over the new session may be helpful. I agree that this may not always be necessary or desirable. But I think it is a policy issue, and the protocol should support it. For instance, if it is an automaton that is doing the sending, it will probably want to retransmit. In the case of a human controlling the sending, if the retransmission isn't handled automatically, then the user will probably do it manually anyway, but then it becomes a bad idea to suppress the possible duplicate. If a human had sent a huge file, he might first send a query "did you get the file?" before resending it, which may not be practical for an automaton to do. If we really wanted to get fancy, we could build in stuff for querying whether a message had been received, or for having the recipient respond in such a way the the resend is aborted if it was already received. But I'm not advocating that right now. >>> 7. Close on keep-alive handling--needs more list discussion. In >>> particular, do keep-alives need to be bi-directional? >> >> Probably not. a keep-alive from one side results in a 200 from the >> other. Therefore both sides are alive. If we can assume that pulling bytes from the connection is a sufficient evidence of liveness of the recipient when receiving a large message then I agree. But for some implementations that may not be good enough. Suppose you had an OS that buffers a *lot* of incoming data. The sender might send to a dead application for a long time without knowing there is a problem. Explicit keepalives by the recipient while receiving the large message would fix this problem. But they would have to be a separate message, with no response, so they could be sent during reception of a large message. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 11:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28677 for ; Tue, 18 Nov 2003 11:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8ju-0005sh-Qj for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 11:30:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGU6Yp022605 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 11:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8ju-0005sW-9y for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 11:30:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28639; Tue, 18 Nov 2003 11:29:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8js-0000CF-00; Tue, 18 Nov 2003 11:30:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM8js-0000CC-00; Tue, 18 Nov 2003 11:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8jo-0005qn-Ue; Tue, 18 Nov 2003 11:30:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8jd-0005q0-Vq for simple@optimus.ietf.org; Tue, 18 Nov 2003 11:29:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28624 for ; Tue, 18 Nov 2003 11:29:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8jc-0000Bh-00 for simple@ietf.org; Tue, 18 Nov 2003 11:29:48 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AM8jb-0000B2-00 for simple@ietf.org; Tue, 18 Nov 2003 11:29:48 -0500 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 08:37:30 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAIGTDtg013945; Tue, 18 Nov 2003 08:29:14 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEB57055; Tue, 18 Nov 2003 11:29:13 -0500 (EST) Message-ID: <3FBA48D9.9050601@cisco.com> 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: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP Open Issues References: <2038BCC78B1AD641891A0D1AE133DBB70194813C@esebe019.ntc.nokia.com> <3FBA377E.8070903@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 11:29:13 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > hisham.khartabil@nokia.com wrote: > >>> 2. Remove text suggesting re-sending failed messages on the same >>> connection. Instead, we should close the connection and re-connect. >>> (See item 3...) >> >> I'm still confused about this one. Long messages might cause a >> time-out at the sender's side. Perhaps we need to define 3 different >> behaviours: >> >> a) a timeout >> b) an error response >> c) broken TCP connection >> >> a) is what I have real concern for when long messages are involved. Is >> the problem gone when relays are removed? Even with relays, of the sort we were planning, timeouts shouldn't have been an issue any more than congestion in the network is. I don't think this has much to do with the size of the message - the timer isn't going to start until the last byte of the message is sent. As long as the connection is point to point or relays pass on data as they get it, there will typically only be a modest amount of data left to transit the connection when the last byte is sent. So the chance of timeout is the same as if the large preceding amount of data hadn't been sent. In fact it is probably less likely because a larger window will have been opened. Nevertheless, congestion could cause timeouts, and we ought to think about the proper recovery from them. The only ones I can think of that makes sense are to give up or eliminate the timeout. Note that this will perhaps get worse if we are going to try again to do a traffic multiplexing relay protocol. > I think the timeout problem goes away with no relays (Although we do > want to make sure we do not paint ourselves into a corner where relays > become impossible.) You can still get congestion, reducing the rate at which you can get data thru the connection. >>> 3. Close on handling of broken TCP connection. We discussed in the >>> meeting that we should be able to reconnect without having to >>> re-signal. (I remember now that we had discussed this before, and had >>> a good reason at that time _not_ to do this--I will attempt to >>> further remember the details so we can decide what currently makes >>> sense.) >> >> One endpoint might crash and reboot. Ports might change so you need to >> re-signal. > > That is certainly a scenario where reconnecting would not work. I think, > though, that we had come up with a reason why reconnecting was _never_ a > good idea; I'm still trying to reconstitute the reasoning. I can recall a couple: - one was a security issue - giving more opportunity for somebody else to try to break in. I'm not convinced this is a valid concern. - if you can reconnect at any time, the host must be listening for new connections all the time. If you say there can only be one, then as soon as that one is received then listening can stop. This is potentially significant. >>> 3.5 Determine if we need explicity un-visit (interacts with 3.) >> >> I think its needed. If the visitor just tears down the TCP connection, >> the host does not know if the visitor deliberately ended the session, >> or if something has gone wrong at the visitor side. > > I agree, _if_ we decide to change the specification so that a dropped > connection no longer automatically destroys the session. This ties in with the proceedure for gracefully closing a connection. The real question is whether you cna tell if the close was graceful without the un-visit. Maybe it is possible if there is signaling that announces the close, and both sides then drain data from the connection. >>> 4. Do we need a cross-connection duplicate suggestion mechanism? I >>> think we said yes, if the new connection is part of the same session >>> as the old. (Needs further list discussion as it interacts with 3...) duplicate *suggestion* mechanism??? I'm suggesting that duplicates be sent when failing over, but I don't require a special mechanism for making the suggestion. :-) (I suppose you mean duplicate *suppression* mechanism.) >> Now you are calling sessions connections? I still think retransmission >> is not needed. I think perhaps we lack the proper vocabulary here. Since SIP is the *session* initiation protocol, and SDP is the *session* description protocol, I believe we must believe that the thing established by an offer/answer exchange of m-lines is a session. In this case we use a TCP connection to implement the session. The case in question is where an offer/answer exchange within a call establishes an MSRP session. Then later, in the same call, another offer/answer exchange establishes a different MSRP session that logically replaces the previous one. Is there some term that describes the concatenation of those two MSRP sessions? I don't think there is, but we need one. It is a bit like "conversation space" as specified in draft-ietf-sipping-cc-framework-03. When there is trouble sending a message over an MSRP session and recovery is attempted by replacing the MSRP session with another in the same conversation space where retransmission of the failed message over the new session may be helpful. I agree that this may not always be necessary or desirable. But I think it is a policy issue, and the protocol should support it. For instance, if it is an automaton that is doing the sending, it will probably want to retransmit. In the case of a human controlling the sending, if the retransmission isn't handled automatically, then the user will probably do it manually anyway, but then it becomes a bad idea to suppress the possible duplicate. If a human had sent a huge file, he might first send a query "did you get the file?" before resending it, which may not be practical for an automaton to do. If we really wanted to get fancy, we could build in stuff for querying whether a message had been received, or for having the recipient respond in such a way the the resend is aborted if it was already received. But I'm not advocating that right now. >>> 7. Close on keep-alive handling--needs more list discussion. In >>> particular, do keep-alives need to be bi-directional? >> >> Probably not. a keep-alive from one side results in a 200 from the >> other. Therefore both sides are alive. If we can assume that pulling bytes from the connection is a sufficient evidence of liveness of the recipient when receiving a large message then I agree. But for some implementations that may not be good enough. Suppose you had an OS that buffers a *lot* of incoming data. The sender might send to a dead application for a long time without knowing there is a problem. Explicit keepalives by the recipient while receiving the large message would fix this problem. But they would have to be a separate message, with no response, so they could be sent during reception of a large message. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 11:51:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29899; Tue, 18 Nov 2003 11:51:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM95E-0000fD-00; Tue, 18 Nov 2003 11:52:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM95D-0000fA-00; Tue, 18 Nov 2003 11:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM956-000866-Co; Tue, 18 Nov 2003 11:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM94j-00084D-Sh for simple@optimus.ietf.org; Tue, 18 Nov 2003 11:51:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29879 for ; Tue, 18 Nov 2003 11:51:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM94i-0000ej-00 for simple@ietf.org; Tue, 18 Nov 2003 11:51:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AM94h-0000eZ-00 for simple@ietf.org; Tue, 18 Nov 2003 11:51:36 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIGpFnG040097; Tue, 18 Nov 2003 10:51:22 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA4DFE.9000108@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG Subject: Re: [Simple] MSRP Open Issues References: <3FB94605.6020501@dynamicsoft.com> <3FBA452B.9070307@ericsson.com> In-Reply-To: <3FBA452B.9070307@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 10:51:10 -0600 Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Ben Campbell wrote: > >> >> 5. Generalize MIME handling to include mime version and allow >> arbitrary MIME headers. >> > > Will this include the possibility of sending all the Content-* headers > in MSRP. So far the draft only includes Content-Type, but I believe > other Content-* headers will be useful (e.g., Content-Transfer-Encoding > or Content-Disposition). That is the general idea. > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 11:52:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29940 for ; Tue, 18 Nov 2003 11:52:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM95G-000886-5V for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 11:52:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGq9rG031249 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 11:52:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM95F-00087w-Ma for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 11:52:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29899; Tue, 18 Nov 2003 11:51:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM95E-0000fD-00; Tue, 18 Nov 2003 11:52:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM95D-0000fA-00; Tue, 18 Nov 2003 11:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM956-000866-Co; Tue, 18 Nov 2003 11:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM94j-00084D-Sh for simple@optimus.ietf.org; Tue, 18 Nov 2003 11:51:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29879 for ; Tue, 18 Nov 2003 11:51:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM94i-0000ej-00 for simple@ietf.org; Tue, 18 Nov 2003 11:51:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AM94h-0000eZ-00 for simple@ietf.org; Tue, 18 Nov 2003 11:51:36 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIGpFnG040097; Tue, 18 Nov 2003 10:51:22 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA4DFE.9000108@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG Subject: Re: [Simple] MSRP Open Issues References: <3FB94605.6020501@dynamicsoft.com> <3FBA452B.9070307@ericsson.com> In-Reply-To: <3FBA452B.9070307@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 10:51:10 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Ben Campbell wrote: > >> >> 5. Generalize MIME handling to include mime version and allow >> arbitrary MIME headers. >> > > Will this include the possibility of sending all the Content-* headers > in MSRP. So far the draft only includes Content-Type, but I believe > other Content-* headers will be useful (e.g., Content-Transfer-Encoding > or Content-Disposition). That is the general idea. > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 12:16:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01704; Tue, 18 Nov 2003 12:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9ST-0001Ew-00; Tue, 18 Nov 2003 12:16:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM9ST-0001En-00; Tue, 18 Nov 2003 12:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9SM-00023s-1T; Tue, 18 Nov 2003 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9S5-000234-9C for simple@optimus.ietf.org; Tue, 18 Nov 2003 12:15:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01605 for ; Tue, 18 Nov 2003 12:15:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9S3-0001Dx-00 for simple@ietf.org; Tue, 18 Nov 2003 12:15:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AM9S3-0001DX-00 for simple@ietf.org; Tue, 18 Nov 2003 12:15:43 -0500 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAIHDBca018801; Tue, 18 Nov 2003 12:13:11 -0500 (EST) Message-ID: <3FBA5323.20203@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> In-Reply-To: <3FB92381.4050007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 12:13:07 -0500 Content-Transfer-Encoding: 7bit Short timeouts are broken, sure, but the fact that NATs have timeouts on bindings is a common behavior. As a result, if there is no traffic on the TCP connection before the timeout occurs, the binding is lost, and any data sent on that connection will fail. Therefore, I think we can expect to see cases where the connections close due to NAT. Now, the question is, do we think we would see periods of inactivity on the messaging will exceed a typical nat timeout? I think they may. I personally tend to leave IM sessions open continuously all day.. -Jonathan R. Ben Campbell wrote: > I have personally encountered this behavior in the wild. I agree, > however, that it was broken, and probably not a normal use case. And as > far as I know, it pretty much killed anything other than hit-and-run > HTTP connections. > > Paul Kyzivat wrote: > >> Cullen, >> >> I don't have any data of my own on this subject, but I hope you are >> right. >> >> It would be a lot simpler if we can continue to assume that the way >> you reestablish an MSRP session is via a reINVITE. The adequacy of >> that was under question if NATs regularly blow away connections. >> >> Paul >> >> Cullen Jennings wrote: >> >>> There was some assertion in the WG meeting that NATs arbitrarily kill >>> TCP >>> connection and the connection needs to be set up again. I'm sure this >>> has >>> happened with broken NATS but I do not feel it is widespread and >>> don't think >>> we should specifically design for it. I do think we should design for >>> graceful failure or recover when things in the network fail but I don't >>> think there is a common case of TCP failing that involves NATs. If there >>> were, many things that do not automatically set up a new TCP connection, >>> like ssh for example, would be nearly unusable through these broken >>> NATs. >>> >>> 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 12:16:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01787 for ; Tue, 18 Nov 2003 12:16:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9Sh-00026l-TB for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 12:16:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIHGNZX008097 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 12:16:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9Sh-00026W-Oh for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 12:16:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01704; Tue, 18 Nov 2003 12:16:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9ST-0001Ew-00; Tue, 18 Nov 2003 12:16:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM9ST-0001En-00; Tue, 18 Nov 2003 12:16:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9SM-00023s-1T; Tue, 18 Nov 2003 12:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9S5-000234-9C for simple@optimus.ietf.org; Tue, 18 Nov 2003 12:15:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01605 for ; Tue, 18 Nov 2003 12:15:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9S3-0001Dx-00 for simple@ietf.org; Tue, 18 Nov 2003 12:15:43 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AM9S3-0001DX-00 for simple@ietf.org; Tue, 18 Nov 2003 12:15:43 -0500 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAIHDBca018801; Tue, 18 Nov 2003 12:13:11 -0500 (EST) Message-ID: <3FBA5323.20203@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> In-Reply-To: <3FB92381.4050007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 12:13:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Short timeouts are broken, sure, but the fact that NATs have timeouts on bindings is a common behavior. As a result, if there is no traffic on the TCP connection before the timeout occurs, the binding is lost, and any data sent on that connection will fail. Therefore, I think we can expect to see cases where the connections close due to NAT. Now, the question is, do we think we would see periods of inactivity on the messaging will exceed a typical nat timeout? I think they may. I personally tend to leave IM sessions open continuously all day.. -Jonathan R. Ben Campbell wrote: > I have personally encountered this behavior in the wild. I agree, > however, that it was broken, and probably not a normal use case. And as > far as I know, it pretty much killed anything other than hit-and-run > HTTP connections. > > Paul Kyzivat wrote: > >> Cullen, >> >> I don't have any data of my own on this subject, but I hope you are >> right. >> >> It would be a lot simpler if we can continue to assume that the way >> you reestablish an MSRP session is via a reINVITE. The adequacy of >> that was under question if NATs regularly blow away connections. >> >> Paul >> >> Cullen Jennings wrote: >> >>> There was some assertion in the WG meeting that NATs arbitrarily kill >>> TCP >>> connection and the connection needs to be set up again. I'm sure this >>> has >>> happened with broken NATS but I do not feel it is widespread and >>> don't think >>> we should specifically design for it. I do think we should design for >>> graceful failure or recover when things in the network fail but I don't >>> think there is a common case of TCP failing that involves NATs. If there >>> were, many things that do not automatically set up a new TCP connection, >>> like ssh for example, would be nearly unusable through these broken >>> NATs. >>> >>> 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 13:12:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04947; Tue, 18 Nov 2003 13:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMALY-0002S3-00; Tue, 18 Nov 2003 13:13:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMALY-0002S0-00; Tue, 18 Nov 2003 13:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMALU-0005VQ-CW; Tue, 18 Nov 2003 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAL7-0005Us-U0 for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:12:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04891 for ; Tue, 18 Nov 2003 13:12:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAL5-0002QP-00 for simple@ietf.org; Tue, 18 Nov 2003 13:12:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMAL4-0002QI-00 for simple@ietf.org; Tue, 18 Nov 2003 13:12:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIIBwnG047560; Tue, 18 Nov 2003 12:12:08 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA60E9.6080501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> In-Reply-To: <3FBA5323.20203@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 12:11:53 -0600 Content-Transfer-Encoding: 7bit When we were having the recent discussion on the inactivity timeout for MS(R)P, I don't think we thought much about the fact that MSRP keepalive messages may also act as NAT binding keepalives. Jonathan Rosenberg wrote: > Short timeouts are broken, sure, but the fact that NATs have timeouts on > bindings is a common behavior. As a result, if there is no traffic on > the TCP connection before the timeout occurs, the binding is lost, and > any data sent on that connection will fail. > > Therefore, I think we can expect to see cases where the connections > close due to NAT. > > Now, the question is, do we think we would see periods of inactivity on > the messaging will exceed a typical nat timeout? I think they may. I > personally tend to leave IM sessions open continuously all day.. > > -Jonathan R. > > Ben Campbell wrote: > >> I have personally encountered this behavior in the wild. I agree, >> however, that it was broken, and probably not a normal use case. And >> as far as I know, it pretty much killed anything other than >> hit-and-run HTTP connections. >> >> Paul Kyzivat wrote: >> >>> Cullen, >>> >>> I don't have any data of my own on this subject, but I hope you are >>> right. >>> >>> It would be a lot simpler if we can continue to assume that the way >>> you reestablish an MSRP session is via a reINVITE. The adequacy of >>> that was under question if NATs regularly blow away connections. >>> >>> Paul >>> >>> Cullen Jennings wrote: >>> >>>> There was some assertion in the WG meeting that NATs arbitrarily >>>> kill TCP >>>> connection and the connection needs to be set up again. I'm sure >>>> this has >>>> happened with broken NATS but I do not feel it is widespread and >>>> don't think >>>> we should specifically design for it. I do think we should design for >>>> graceful failure or recover when things in the network fail but I don't >>>> think there is a common case of TCP failing that involves NATs. If >>>> there >>>> were, many things that do not automatically set up a new TCP >>>> connection, >>>> like ssh for example, would be nearly unusable through these broken >>>> NATs. >>>> >>>> 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 >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 13:13:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04991 for ; Tue, 18 Nov 2003 13:13:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMALc-0005WT-EX for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:13:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIID8fm021223 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMALa-0005WE-Tt for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 13:13:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04947; Tue, 18 Nov 2003 13:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMALY-0002S3-00; Tue, 18 Nov 2003 13:13:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMALY-0002S0-00; Tue, 18 Nov 2003 13:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMALU-0005VQ-CW; Tue, 18 Nov 2003 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAL7-0005Us-U0 for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:12:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04891 for ; Tue, 18 Nov 2003 13:12:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAL5-0002QP-00 for simple@ietf.org; Tue, 18 Nov 2003 13:12:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMAL4-0002QI-00 for simple@ietf.org; Tue, 18 Nov 2003 13:12:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIIBwnG047560; Tue, 18 Nov 2003 12:12:08 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA60E9.6080501@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> In-Reply-To: <3FBA5323.20203@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 12:11:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit When we were having the recent discussion on the inactivity timeout for MS(R)P, I don't think we thought much about the fact that MSRP keepalive messages may also act as NAT binding keepalives. Jonathan Rosenberg wrote: > Short timeouts are broken, sure, but the fact that NATs have timeouts on > bindings is a common behavior. As a result, if there is no traffic on > the TCP connection before the timeout occurs, the binding is lost, and > any data sent on that connection will fail. > > Therefore, I think we can expect to see cases where the connections > close due to NAT. > > Now, the question is, do we think we would see periods of inactivity on > the messaging will exceed a typical nat timeout? I think they may. I > personally tend to leave IM sessions open continuously all day.. > > -Jonathan R. > > Ben Campbell wrote: > >> I have personally encountered this behavior in the wild. I agree, >> however, that it was broken, and probably not a normal use case. And >> as far as I know, it pretty much killed anything other than >> hit-and-run HTTP connections. >> >> Paul Kyzivat wrote: >> >>> Cullen, >>> >>> I don't have any data of my own on this subject, but I hope you are >>> right. >>> >>> It would be a lot simpler if we can continue to assume that the way >>> you reestablish an MSRP session is via a reINVITE. The adequacy of >>> that was under question if NATs regularly blow away connections. >>> >>> Paul >>> >>> Cullen Jennings wrote: >>> >>>> There was some assertion in the WG meeting that NATs arbitrarily >>>> kill TCP >>>> connection and the connection needs to be set up again. I'm sure >>>> this has >>>> happened with broken NATS but I do not feel it is widespread and >>>> don't think >>>> we should specifically design for it. I do think we should design for >>>> graceful failure or recover when things in the network fail but I don't >>>> think there is a common case of TCP failing that involves NATs. If >>>> there >>>> were, many things that do not automatically set up a new TCP >>>> connection, >>>> like ssh for example, would be nearly unusable through these broken >>>> NATs. >>>> >>>> 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 >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 13:18:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05241; Tue, 18 Nov 2003 13:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMARM-0002ZS-00; Tue, 18 Nov 2003 13:19:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMARL-0002ZP-00; Tue, 18 Nov 2003 13:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMARK-0005pM-0s; Tue, 18 Nov 2003 13:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAQZ-0005oG-0P for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05203 for ; Tue, 18 Nov 2003 13:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAQX-0002YA-00 for simple@ietf.org; Tue, 18 Nov 2003 13:18:13 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMAQW-0002XT-00 for simple@ietf.org; Tue, 18 Nov 2003 13:18:12 -0500 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAIIH4ca018822; Tue, 18 Nov 2003 13:17:05 -0500 (EST) Message-ID: <3FBA621C.3060507@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> In-Reply-To: <3FBA60E9.6080501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 13:17:00 -0500 Content-Transfer-Encoding: 7bit The trick, as always, is knowing what the nat keepalive is. There is no easy way to know. -Jonathan R. Ben Campbell wrote: > When we were having the recent discussion on the inactivity timeout for > MS(R)P, I don't think we thought much about the fact that MSRP keepalive > messages may also act as NAT binding keepalives. > > > > Jonathan Rosenberg wrote: > >> Short timeouts are broken, sure, but the fact that NATs have timeouts >> on bindings is a common behavior. As a result, if there is no traffic >> on the TCP connection before the timeout occurs, the binding is lost, >> and any data sent on that connection will fail. >> >> Therefore, I think we can expect to see cases where the connections >> close due to NAT. >> >> Now, the question is, do we think we would see periods of inactivity >> on the messaging will exceed a typical nat timeout? I think they may. >> I personally tend to leave IM sessions open continuously all day.. >> >> -Jonathan R. >> >> Ben Campbell wrote: >> >>> I have personally encountered this behavior in the wild. I agree, >>> however, that it was broken, and probably not a normal use case. And >>> as far as I know, it pretty much killed anything other than >>> hit-and-run HTTP connections. >>> >>> Paul Kyzivat wrote: >>> >>>> Cullen, >>>> >>>> I don't have any data of my own on this subject, but I hope you are >>>> right. >>>> >>>> It would be a lot simpler if we can continue to assume that the way >>>> you reestablish an MSRP session is via a reINVITE. The adequacy of >>>> that was under question if NATs regularly blow away connections. >>>> >>>> Paul >>>> >>>> Cullen Jennings wrote: >>>> >>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>> kill TCP >>>>> connection and the connection needs to be set up again. I'm sure >>>>> this has >>>>> happened with broken NATS but I do not feel it is widespread and >>>>> don't think >>>>> we should specifically design for it. I do think we should design for >>>>> graceful failure or recover when things in the network fail but I >>>>> don't >>>>> think there is a common case of TCP failing that involves NATs. If >>>>> there >>>>> were, many things that do not automatically set up a new TCP >>>>> connection, >>>>> like ssh for example, would be nearly unusable through these broken >>>>> NATs. >>>>> >>>>> 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 >>> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 13:19:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05304 for ; Tue, 18 Nov 2003 13:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMARO-0005rm-O7 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIIJ673022544 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMARO-0005rX-Io for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 13:19:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05241; Tue, 18 Nov 2003 13:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMARM-0002ZS-00; Tue, 18 Nov 2003 13:19:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMARL-0002ZP-00; Tue, 18 Nov 2003 13:19:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMARK-0005pM-0s; Tue, 18 Nov 2003 13:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAQZ-0005oG-0P for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:18:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05203 for ; Tue, 18 Nov 2003 13:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAQX-0002YA-00 for simple@ietf.org; Tue, 18 Nov 2003 13:18:13 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMAQW-0002XT-00 for simple@ietf.org; Tue, 18 Nov 2003 13:18:12 -0500 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAIIH4ca018822; Tue, 18 Nov 2003 13:17:05 -0500 (EST) Message-ID: <3FBA621C.3060507@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Paul Kyzivat , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> In-Reply-To: <3FBA60E9.6080501@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 13:17:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The trick, as always, is knowing what the nat keepalive is. There is no easy way to know. -Jonathan R. Ben Campbell wrote: > When we were having the recent discussion on the inactivity timeout for > MS(R)P, I don't think we thought much about the fact that MSRP keepalive > messages may also act as NAT binding keepalives. > > > > Jonathan Rosenberg wrote: > >> Short timeouts are broken, sure, but the fact that NATs have timeouts >> on bindings is a common behavior. As a result, if there is no traffic >> on the TCP connection before the timeout occurs, the binding is lost, >> and any data sent on that connection will fail. >> >> Therefore, I think we can expect to see cases where the connections >> close due to NAT. >> >> Now, the question is, do we think we would see periods of inactivity >> on the messaging will exceed a typical nat timeout? I think they may. >> I personally tend to leave IM sessions open continuously all day.. >> >> -Jonathan R. >> >> Ben Campbell wrote: >> >>> I have personally encountered this behavior in the wild. I agree, >>> however, that it was broken, and probably not a normal use case. And >>> as far as I know, it pretty much killed anything other than >>> hit-and-run HTTP connections. >>> >>> Paul Kyzivat wrote: >>> >>>> Cullen, >>>> >>>> I don't have any data of my own on this subject, but I hope you are >>>> right. >>>> >>>> It would be a lot simpler if we can continue to assume that the way >>>> you reestablish an MSRP session is via a reINVITE. The adequacy of >>>> that was under question if NATs regularly blow away connections. >>>> >>>> Paul >>>> >>>> Cullen Jennings wrote: >>>> >>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>> kill TCP >>>>> connection and the connection needs to be set up again. I'm sure >>>>> this has >>>>> happened with broken NATS but I do not feel it is widespread and >>>>> don't think >>>>> we should specifically design for it. I do think we should design for >>>>> graceful failure or recover when things in the network fail but I >>>>> don't >>>>> think there is a common case of TCP failing that involves NATs. If >>>>> there >>>>> were, many things that do not automatically set up a new TCP >>>>> connection, >>>>> like ssh for example, would be nearly unusable through these broken >>>>> NATs. >>>>> >>>>> 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 >>> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 13:31:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05944; Tue, 18 Nov 2003 13:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAdt-0002qz-00; Tue, 18 Nov 2003 13:32:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMAdt-0002qw-00; Tue, 18 Nov 2003 13:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAdt-0006lN-1n; Tue, 18 Nov 2003 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAcy-0006kS-Ba for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:31:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05898 for ; Tue, 18 Nov 2003 13:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAcw-0002nQ-00 for simple@ietf.org; Tue, 18 Nov 2003 13:31:02 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMAcv-0002n0-00 for simple@ietf.org; Tue, 18 Nov 2003 13:31:01 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAIIUSAt013086; Tue, 18 Nov 2003 10:30:29 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEB71437; Tue, 18 Nov 2003 13:30:27 -0500 (EST) Message-ID: <3FBA6543.1090307@cisco.com> 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: Jonathan Rosenberg CC: Ben Campbell , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> <3FBA621C.3060507@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 13:30:27 -0500 Content-Transfer-Encoding: 7bit Letting msrp keepalives act as NAT binding keepalives seems attractive. Perhaps the NAT keepalive time needs to be determined adaptively. If the connection is found to be down, a reinvite could reconstruct it, and a new keepalive timer could be set, shorter than before. But this would require negotiating the keepalive time. Paul Jonathan Rosenberg wrote: > The trick, as always, is knowing what the nat keepalive is. There is no > easy way to know. > > -Jonathan R. > > Ben Campbell wrote: > >> When we were having the recent discussion on the inactivity timeout >> for MS(R)P, I don't think we thought much about the fact that MSRP >> keepalive messages may also act as NAT binding keepalives. >> >> >> >> Jonathan Rosenberg wrote: >> >>> Short timeouts are broken, sure, but the fact that NATs have timeouts >>> on bindings is a common behavior. As a result, if there is no traffic >>> on the TCP connection before the timeout occurs, the binding is lost, >>> and any data sent on that connection will fail. >>> >>> Therefore, I think we can expect to see cases where the connections >>> close due to NAT. >>> >>> Now, the question is, do we think we would see periods of inactivity >>> on the messaging will exceed a typical nat timeout? I think they may. >>> I personally tend to leave IM sessions open continuously all day.. >>> >>> -Jonathan R. >>> >>> Ben Campbell wrote: >>> >>>> I have personally encountered this behavior in the wild. I agree, >>>> however, that it was broken, and probably not a normal use case. And >>>> as far as I know, it pretty much killed anything other than >>>> hit-and-run HTTP connections. >>>> >>>> Paul Kyzivat wrote: >>>> >>>>> Cullen, >>>>> >>>>> I don't have any data of my own on this subject, but I hope you are >>>>> right. >>>>> >>>>> It would be a lot simpler if we can continue to assume that the way >>>>> you reestablish an MSRP session is via a reINVITE. The adequacy of >>>>> that was under question if NATs regularly blow away connections. >>>>> >>>>> Paul >>>>> >>>>> Cullen Jennings wrote: >>>>> >>>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>>> kill TCP >>>>>> connection and the connection needs to be set up again. I'm sure >>>>>> this has >>>>>> happened with broken NATS but I do not feel it is widespread and >>>>>> don't think >>>>>> we should specifically design for it. I do think we should design for >>>>>> graceful failure or recover when things in the network fail but I >>>>>> don't >>>>>> think there is a common case of TCP failing that involves NATs. If >>>>>> there >>>>>> were, many things that do not automatically set up a new TCP >>>>>> connection, >>>>>> like ssh for example, would be nearly unusable through these >>>>>> broken NATs. >>>>>> >>>>>> 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 >>>> >>> >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 13:32:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05974 for ; Tue, 18 Nov 2003 13:32:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAdx-0006nG-Tv for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIIW5co026113 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAdx-0006n5-Pk for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 13:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05944; Tue, 18 Nov 2003 13:31:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAdt-0002qz-00; Tue, 18 Nov 2003 13:32:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMAdt-0002qw-00; Tue, 18 Nov 2003 13:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAdt-0006lN-1n; Tue, 18 Nov 2003 13:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAcy-0006kS-Ba for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:31:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05898 for ; Tue, 18 Nov 2003 13:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAcw-0002nQ-00 for simple@ietf.org; Tue, 18 Nov 2003 13:31:02 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMAcv-0002n0-00 for simple@ietf.org; Tue, 18 Nov 2003 13:31:01 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAIIUSAt013086; Tue, 18 Nov 2003 10:30:29 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEB71437; Tue, 18 Nov 2003 13:30:27 -0500 (EST) Message-ID: <3FBA6543.1090307@cisco.com> 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: Jonathan Rosenberg CC: Ben Campbell , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> <3FBA621C.3060507@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 13:30:27 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Letting msrp keepalives act as NAT binding keepalives seems attractive. Perhaps the NAT keepalive time needs to be determined adaptively. If the connection is found to be down, a reinvite could reconstruct it, and a new keepalive timer could be set, shorter than before. But this would require negotiating the keepalive time. Paul Jonathan Rosenberg wrote: > The trick, as always, is knowing what the nat keepalive is. There is no > easy way to know. > > -Jonathan R. > > Ben Campbell wrote: > >> When we were having the recent discussion on the inactivity timeout >> for MS(R)P, I don't think we thought much about the fact that MSRP >> keepalive messages may also act as NAT binding keepalives. >> >> >> >> Jonathan Rosenberg wrote: >> >>> Short timeouts are broken, sure, but the fact that NATs have timeouts >>> on bindings is a common behavior. As a result, if there is no traffic >>> on the TCP connection before the timeout occurs, the binding is lost, >>> and any data sent on that connection will fail. >>> >>> Therefore, I think we can expect to see cases where the connections >>> close due to NAT. >>> >>> Now, the question is, do we think we would see periods of inactivity >>> on the messaging will exceed a typical nat timeout? I think they may. >>> I personally tend to leave IM sessions open continuously all day.. >>> >>> -Jonathan R. >>> >>> Ben Campbell wrote: >>> >>>> I have personally encountered this behavior in the wild. I agree, >>>> however, that it was broken, and probably not a normal use case. And >>>> as far as I know, it pretty much killed anything other than >>>> hit-and-run HTTP connections. >>>> >>>> Paul Kyzivat wrote: >>>> >>>>> Cullen, >>>>> >>>>> I don't have any data of my own on this subject, but I hope you are >>>>> right. >>>>> >>>>> It would be a lot simpler if we can continue to assume that the way >>>>> you reestablish an MSRP session is via a reINVITE. The adequacy of >>>>> that was under question if NATs regularly blow away connections. >>>>> >>>>> Paul >>>>> >>>>> Cullen Jennings wrote: >>>>> >>>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>>> kill TCP >>>>>> connection and the connection needs to be set up again. I'm sure >>>>>> this has >>>>>> happened with broken NATS but I do not feel it is widespread and >>>>>> don't think >>>>>> we should specifically design for it. I do think we should design for >>>>>> graceful failure or recover when things in the network fail but I >>>>>> don't >>>>>> think there is a common case of TCP failing that involves NATs. If >>>>>> there >>>>>> were, many things that do not automatically set up a new TCP >>>>>> connection, >>>>>> like ssh for example, would be nearly unusable through these >>>>>> broken NATs. >>>>>> >>>>>> 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 >>>> >>> >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 13:36:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06123; Tue, 18 Nov 2003 13:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAij-0002uX-00; Tue, 18 Nov 2003 13:37:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMAij-0002uR-00; Tue, 18 Nov 2003 13:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAij-00070s-90; Tue, 18 Nov 2003 13:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAiG-00070Q-O9 for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:36:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06110 for ; Tue, 18 Nov 2003 13:36:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAiE-0002u2-00 for simple@ietf.org; Tue, 18 Nov 2003 13:36:30 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMAiD-0002tz-00 for simple@ietf.org; Tue, 18 Nov 2003 13:36:29 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIIZ9nG049377; Tue, 18 Nov 2003 12:35:16 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA6658.40204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> <3FBA621C.3060507@dynamicsoft.com> <3FBA6543.1090307@cisco.com> In-Reply-To: <3FBA6543.1090307@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 12:35:04 -0600 Content-Transfer-Encoding: 7bit Can we reasonably assume that all connection failures are due to NATs? What happens if endpoints do this when the failure is caused by something else? Paul Kyzivat wrote: > Letting msrp keepalives act as NAT binding keepalives seems attractive. > Perhaps the NAT keepalive time needs to be determined adaptively. If the > connection is found to be down, a reinvite could reconstruct it, and a > new keepalive timer could be set, shorter than before. > > But this would require negotiating the keepalive time. > > Paul > > Jonathan Rosenberg wrote: > >> The trick, as always, is knowing what the nat keepalive is. There is >> no easy way to know. >> >> -Jonathan R. >> >> Ben Campbell wrote: >> >>> When we were having the recent discussion on the inactivity timeout >>> for MS(R)P, I don't think we thought much about the fact that MSRP >>> keepalive messages may also act as NAT binding keepalives. >>> >>> >>> >>> Jonathan Rosenberg wrote: >>> >>>> Short timeouts are broken, sure, but the fact that NATs have >>>> timeouts on bindings is a common behavior. As a result, if there is >>>> no traffic on the TCP connection before the timeout occurs, the >>>> binding is lost, and any data sent on that connection will fail. >>>> >>>> Therefore, I think we can expect to see cases where the connections >>>> close due to NAT. >>>> >>>> Now, the question is, do we think we would see periods of inactivity >>>> on the messaging will exceed a typical nat timeout? I think they >>>> may. I personally tend to leave IM sessions open continuously all day.. >>>> >>>> -Jonathan R. >>>> >>>> Ben Campbell wrote: >>>> >>>>> I have personally encountered this behavior in the wild. I agree, >>>>> however, that it was broken, and probably not a normal use case. >>>>> And as far as I know, it pretty much killed anything other than >>>>> hit-and-run HTTP connections. >>>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> Cullen, >>>>>> >>>>>> I don't have any data of my own on this subject, but I hope you >>>>>> are right. >>>>>> >>>>>> It would be a lot simpler if we can continue to assume that the >>>>>> way you reestablish an MSRP session is via a reINVITE. The >>>>>> adequacy of that was under question if NATs regularly blow away >>>>>> connections. >>>>>> >>>>>> Paul >>>>>> >>>>>> Cullen Jennings wrote: >>>>>> >>>>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>>>> kill TCP >>>>>>> connection and the connection needs to be set up again. I'm sure >>>>>>> this has >>>>>>> happened with broken NATS but I do not feel it is widespread and >>>>>>> don't think >>>>>>> we should specifically design for it. I do think we should design >>>>>>> for >>>>>>> graceful failure or recover when things in the network fail but I >>>>>>> don't >>>>>>> think there is a common case of TCP failing that involves NATs. >>>>>>> If there >>>>>>> were, many things that do not automatically set up a new TCP >>>>>>> connection, >>>>>>> like ssh for example, would be nearly unusable through these >>>>>>> broken NATs. >>>>>>> >>>>>>> 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 >>>>> >>>> >>> >>> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 13:37:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06162 for ; Tue, 18 Nov 2003 13:37:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAin-00073y-Ht for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:37:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIIb5DQ027136 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 13:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAim-000737-ID for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 13:37:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06123; Tue, 18 Nov 2003 13:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAij-0002uX-00; Tue, 18 Nov 2003 13:37:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMAij-0002uR-00; Tue, 18 Nov 2003 13:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAij-00070s-90; Tue, 18 Nov 2003 13:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMAiG-00070Q-O9 for simple@optimus.ietf.org; Tue, 18 Nov 2003 13:36:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06110 for ; Tue, 18 Nov 2003 13:36:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMAiE-0002u2-00 for simple@ietf.org; Tue, 18 Nov 2003 13:36:30 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMAiD-0002tz-00 for simple@ietf.org; Tue, 18 Nov 2003 13:36:29 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAIIZ9nG049377; Tue, 18 Nov 2003 12:35:16 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBA6658.40204@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> <3FBA621C.3060507@dynamicsoft.com> <3FBA6543.1090307@cisco.com> In-Reply-To: <3FBA6543.1090307@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 12:35:04 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Can we reasonably assume that all connection failures are due to NATs? What happens if endpoints do this when the failure is caused by something else? Paul Kyzivat wrote: > Letting msrp keepalives act as NAT binding keepalives seems attractive. > Perhaps the NAT keepalive time needs to be determined adaptively. If the > connection is found to be down, a reinvite could reconstruct it, and a > new keepalive timer could be set, shorter than before. > > But this would require negotiating the keepalive time. > > Paul > > Jonathan Rosenberg wrote: > >> The trick, as always, is knowing what the nat keepalive is. There is >> no easy way to know. >> >> -Jonathan R. >> >> Ben Campbell wrote: >> >>> When we were having the recent discussion on the inactivity timeout >>> for MS(R)P, I don't think we thought much about the fact that MSRP >>> keepalive messages may also act as NAT binding keepalives. >>> >>> >>> >>> Jonathan Rosenberg wrote: >>> >>>> Short timeouts are broken, sure, but the fact that NATs have >>>> timeouts on bindings is a common behavior. As a result, if there is >>>> no traffic on the TCP connection before the timeout occurs, the >>>> binding is lost, and any data sent on that connection will fail. >>>> >>>> Therefore, I think we can expect to see cases where the connections >>>> close due to NAT. >>>> >>>> Now, the question is, do we think we would see periods of inactivity >>>> on the messaging will exceed a typical nat timeout? I think they >>>> may. I personally tend to leave IM sessions open continuously all day.. >>>> >>>> -Jonathan R. >>>> >>>> Ben Campbell wrote: >>>> >>>>> I have personally encountered this behavior in the wild. I agree, >>>>> however, that it was broken, and probably not a normal use case. >>>>> And as far as I know, it pretty much killed anything other than >>>>> hit-and-run HTTP connections. >>>>> >>>>> Paul Kyzivat wrote: >>>>> >>>>>> Cullen, >>>>>> >>>>>> I don't have any data of my own on this subject, but I hope you >>>>>> are right. >>>>>> >>>>>> It would be a lot simpler if we can continue to assume that the >>>>>> way you reestablish an MSRP session is via a reINVITE. The >>>>>> adequacy of that was under question if NATs regularly blow away >>>>>> connections. >>>>>> >>>>>> Paul >>>>>> >>>>>> Cullen Jennings wrote: >>>>>> >>>>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>>>> kill TCP >>>>>>> connection and the connection needs to be set up again. I'm sure >>>>>>> this has >>>>>>> happened with broken NATS but I do not feel it is widespread and >>>>>>> don't think >>>>>>> we should specifically design for it. I do think we should design >>>>>>> for >>>>>>> graceful failure or recover when things in the network fail but I >>>>>>> don't >>>>>>> think there is a common case of TCP failing that involves NATs. >>>>>>> If there >>>>>>> were, many things that do not automatically set up a new TCP >>>>>>> connection, >>>>>>> like ssh for example, would be nearly unusable through these >>>>>>> broken NATs. >>>>>>> >>>>>>> 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 >>>>> >>>> >>> >>> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 14:15:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07734; Tue, 18 Nov 2003 14:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMBKP-0003Uq-00; Tue, 18 Nov 2003 14:15:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMBKO-0003UZ-00; Tue, 18 Nov 2003 14:15:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBJW-000113-2q; Tue, 18 Nov 2003 14:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBJ6-0000y3-8S for simple@optimus.ietf.org; Tue, 18 Nov 2003 14:14:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07693 for ; Tue, 18 Nov 2003 14:14:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMBJ3-0003UD-00 for simple@ietf.org; Tue, 18 Nov 2003 14:14:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMBJ3-0003U1-00 for simple@ietf.org; Tue, 18 Nov 2003 14:14:33 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIJDww7012346; Tue, 18 Nov 2003 11:14:01 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEB76501; Tue, 18 Nov 2003 14:12:41 -0500 (EST) Message-ID: <3FBA6F29.1000409@cisco.com> 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: Ben Campbell CC: Jonathan Rosenberg , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> <3FBA621C.3060507@dynamicsoft.com> <3FBA6543.1090307@cisco.com> <3FBA6658.40204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 14:12:41 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Can we reasonably assume that all connection failures are due to NATs? > What happens if endpoints do this when the failure is caused by > something else? Good point. That could be ugly - I don't see any easy way to know when the connection fails because of NAT. Lacking that it seems infeasible to test for the NAT timeout interval. Are there any standard practices in this regard? In other words, is there a keepalive time we could use that would be sufficient most of the time and still not be too impractical to keep up? Paul > Paul Kyzivat wrote: > >> Letting msrp keepalives act as NAT binding keepalives seems >> attractive. Perhaps the NAT keepalive time needs to be determined >> adaptively. If the connection is found to be down, a reinvite could >> reconstruct it, and a new keepalive timer could be set, shorter than >> before. >> >> But this would require negotiating the keepalive time. >> >> Paul >> >> Jonathan Rosenberg wrote: >> >>> The trick, as always, is knowing what the nat keepalive is. There is >>> no easy way to know. >>> >>> -Jonathan R. >>> >>> Ben Campbell wrote: >>> >>>> When we were having the recent discussion on the inactivity timeout >>>> for MS(R)P, I don't think we thought much about the fact that MSRP >>>> keepalive messages may also act as NAT binding keepalives. >>>> >>>> >>>> >>>> Jonathan Rosenberg wrote: >>>> >>>>> Short timeouts are broken, sure, but the fact that NATs have >>>>> timeouts on bindings is a common behavior. As a result, if there is >>>>> no traffic on the TCP connection before the timeout occurs, the >>>>> binding is lost, and any data sent on that connection will fail. >>>>> >>>>> Therefore, I think we can expect to see cases where the connections >>>>> close due to NAT. >>>>> >>>>> Now, the question is, do we think we would see periods of >>>>> inactivity on the messaging will exceed a typical nat timeout? I >>>>> think they may. I personally tend to leave IM sessions open >>>>> continuously all day.. >>>>> >>>>> -Jonathan R. >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> I have personally encountered this behavior in the wild. I agree, >>>>>> however, that it was broken, and probably not a normal use case. >>>>>> And as far as I know, it pretty much killed anything other than >>>>>> hit-and-run HTTP connections. >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> Cullen, >>>>>>> >>>>>>> I don't have any data of my own on this subject, but I hope you >>>>>>> are right. >>>>>>> >>>>>>> It would be a lot simpler if we can continue to assume that the >>>>>>> way you reestablish an MSRP session is via a reINVITE. The >>>>>>> adequacy of that was under question if NATs regularly blow away >>>>>>> connections. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Cullen Jennings wrote: >>>>>>> >>>>>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>>>>> kill TCP >>>>>>>> connection and the connection needs to be set up again. I'm sure >>>>>>>> this has >>>>>>>> happened with broken NATS but I do not feel it is widespread and >>>>>>>> don't think >>>>>>>> we should specifically design for it. I do think we should >>>>>>>> design for >>>>>>>> graceful failure or recover when things in the network fail but >>>>>>>> I don't >>>>>>>> think there is a common case of TCP failing that involves NATs. >>>>>>>> If there >>>>>>>> were, many things that do not automatically set up a new TCP >>>>>>>> connection, >>>>>>>> like ssh for example, would be nearly unusable through these >>>>>>>> broken NATs. >>>>>>>> >>>>>>>> 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 >>>>>> >>>>> >>>> >>>> >>> > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 14:16:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07797 for ; Tue, 18 Nov 2003 14:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBKU-00016R-4U for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 14:16:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIJG1V6004218 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 14:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBKT-00015k-6r for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 14:16:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07734; Tue, 18 Nov 2003 14:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMBKP-0003Uq-00; Tue, 18 Nov 2003 14:15:57 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMBKO-0003UZ-00; Tue, 18 Nov 2003 14:15:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBJW-000113-2q; Tue, 18 Nov 2003 14:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMBJ6-0000y3-8S for simple@optimus.ietf.org; Tue, 18 Nov 2003 14:14:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07693 for ; Tue, 18 Nov 2003 14:14:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMBJ3-0003UD-00 for simple@ietf.org; Tue, 18 Nov 2003 14:14:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMBJ3-0003U1-00 for simple@ietf.org; Tue, 18 Nov 2003 14:14:33 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIJDww7012346; Tue, 18 Nov 2003 11:14:01 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEB76501; Tue, 18 Nov 2003 14:12:41 -0500 (EST) Message-ID: <3FBA6F29.1000409@cisco.com> 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: Ben Campbell CC: Jonathan Rosenberg , Cullen Jennings , simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <3FB8D992.8080601@cisco.com> <3FB92381.4050007@dynamicsoft.com> <3FBA5323.20203@dynamicsoft.com> <3FBA60E9.6080501@dynamicsoft.com> <3FBA621C.3060507@dynamicsoft.com> <3FBA6543.1090307@cisco.com> <3FBA6658.40204@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 14:12:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Can we reasonably assume that all connection failures are due to NATs? > What happens if endpoints do this when the failure is caused by > something else? Good point. That could be ugly - I don't see any easy way to know when the connection fails because of NAT. Lacking that it seems infeasible to test for the NAT timeout interval. Are there any standard practices in this regard? In other words, is there a keepalive time we could use that would be sufficient most of the time and still not be too impractical to keep up? Paul > Paul Kyzivat wrote: > >> Letting msrp keepalives act as NAT binding keepalives seems >> attractive. Perhaps the NAT keepalive time needs to be determined >> adaptively. If the connection is found to be down, a reinvite could >> reconstruct it, and a new keepalive timer could be set, shorter than >> before. >> >> But this would require negotiating the keepalive time. >> >> Paul >> >> Jonathan Rosenberg wrote: >> >>> The trick, as always, is knowing what the nat keepalive is. There is >>> no easy way to know. >>> >>> -Jonathan R. >>> >>> Ben Campbell wrote: >>> >>>> When we were having the recent discussion on the inactivity timeout >>>> for MS(R)P, I don't think we thought much about the fact that MSRP >>>> keepalive messages may also act as NAT binding keepalives. >>>> >>>> >>>> >>>> Jonathan Rosenberg wrote: >>>> >>>>> Short timeouts are broken, sure, but the fact that NATs have >>>>> timeouts on bindings is a common behavior. As a result, if there is >>>>> no traffic on the TCP connection before the timeout occurs, the >>>>> binding is lost, and any data sent on that connection will fail. >>>>> >>>>> Therefore, I think we can expect to see cases where the connections >>>>> close due to NAT. >>>>> >>>>> Now, the question is, do we think we would see periods of >>>>> inactivity on the messaging will exceed a typical nat timeout? I >>>>> think they may. I personally tend to leave IM sessions open >>>>> continuously all day.. >>>>> >>>>> -Jonathan R. >>>>> >>>>> Ben Campbell wrote: >>>>> >>>>>> I have personally encountered this behavior in the wild. I agree, >>>>>> however, that it was broken, and probably not a normal use case. >>>>>> And as far as I know, it pretty much killed anything other than >>>>>> hit-and-run HTTP connections. >>>>>> >>>>>> Paul Kyzivat wrote: >>>>>> >>>>>>> Cullen, >>>>>>> >>>>>>> I don't have any data of my own on this subject, but I hope you >>>>>>> are right. >>>>>>> >>>>>>> It would be a lot simpler if we can continue to assume that the >>>>>>> way you reestablish an MSRP session is via a reINVITE. The >>>>>>> adequacy of that was under question if NATs regularly blow away >>>>>>> connections. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> Cullen Jennings wrote: >>>>>>> >>>>>>>> There was some assertion in the WG meeting that NATs arbitrarily >>>>>>>> kill TCP >>>>>>>> connection and the connection needs to be set up again. I'm sure >>>>>>>> this has >>>>>>>> happened with broken NATS but I do not feel it is widespread and >>>>>>>> don't think >>>>>>>> we should specifically design for it. I do think we should >>>>>>>> design for >>>>>>>> graceful failure or recover when things in the network fail but >>>>>>>> I don't >>>>>>>> think there is a common case of TCP failing that involves NATs. >>>>>>>> If there >>>>>>>> were, many things that do not automatically set up a new TCP >>>>>>>> connection, >>>>>>>> like ssh for example, would be nearly unusable through these >>>>>>>> broken NATs. >>>>>>>> >>>>>>>> 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 >>>>>> >>>>> >>>> >>>> >>> > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 17:54:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23113; Tue, 18 Nov 2003 17:54:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEjd-0001bh-00; Tue, 18 Nov 2003 17:54:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMEjd-0001be-00; Tue, 18 Nov 2003 17:54:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEjR-0007DC-51; Tue, 18 Nov 2003 17:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEj8-0007CT-9q for simple@optimus.ietf.org; Tue, 18 Nov 2003 17:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23071 for ; Tue, 18 Nov 2003 17:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEj2-0001ak-00 for simple@ietf.org; Tue, 18 Nov 2003 17:53:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMEj1-0001a1-00 for simple@ietf.org; Tue, 18 Nov 2003 17:53:35 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 15:01:23 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIMr3w5008092; Tue, 18 Nov 2003 14:53:03 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB38541; Tue, 18 Nov 2003 14:52:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] IM and file transfer From: Cullen Jennings To: Ben Campbell CC: Adam Roach , "'Aki Niemi'" , Message-ID: In-Reply-To: <3FB92574.60407@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 14:52:58 -0800 Content-Transfer-Encoding: 7bit On 11/17/03 11:45 AM, "Ben Campbell" wrote: > Cullen Jennings wrote: > >> On 11/11/03 9:27 AM, "Adam Roach" wrote: >> >> >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >>> >>> >>>> These are somewhat orthogonal aspects of a message session. It is >>>> probably useful to label a specific session as e.g., file-transfer >>> >>> Yes. You do this by using port 21. If you know a priori that all >>> you are going to do is transfer files, the IETF has already >>> defined a file transfer protocol. >> >> >> Yes, and FTP meets my end user to end user file transfer needs somewhat less >> well than IRC meets my IMPP needs. File transfer is a requirement for any >> viable modern IM application. FTP will still be used for places where it >> meets the needs. > > I agree that it is a requirement for any modern application. That does > not necessarily make it a requirement of a particular protocol. I know > that under certain conditions, the mechanism yahoo uses for file > transfer is very different than the mechanism it uses for IM transport. > > It would be well within reason for us to specify how to securly signal > ftp sessions via SIP. > > That all being said, we established a consensus that MSRP (Or should > that be MSP now?) was expected to be able to carry arbitrarily large > content. I very much doubt that consensus has changed. Yes - that makes sense - sorry I brought up the topic again. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 17:54:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23159 for ; Tue, 18 Nov 2003 17:54:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEjg-0007Ep-OQ for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 17:54:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIMsGYf027823 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 17:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEjg-0007Eg-LC for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 17:54:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23113; Tue, 18 Nov 2003 17:54:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEjd-0001bh-00; Tue, 18 Nov 2003 17:54:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMEjd-0001be-00; Tue, 18 Nov 2003 17:54:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEjR-0007DC-51; Tue, 18 Nov 2003 17:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMEj8-0007CT-9q for simple@optimus.ietf.org; Tue, 18 Nov 2003 17:53:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23071 for ; Tue, 18 Nov 2003 17:53:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMEj2-0001ak-00 for simple@ietf.org; Tue, 18 Nov 2003 17:53:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMEj1-0001a1-00 for simple@ietf.org; Tue, 18 Nov 2003 17:53:35 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Nov 2003 15:01:23 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAIMr3w5008092; Tue, 18 Nov 2003 14:53:03 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB38541; Tue, 18 Nov 2003 14:52:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] IM and file transfer From: Cullen Jennings To: Ben Campbell CC: Adam Roach , "'Aki Niemi'" , Message-ID: In-Reply-To: <3FB92574.60407@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 14:52:58 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/17/03 11:45 AM, "Ben Campbell" wrote: > Cullen Jennings wrote: > >> On 11/11/03 9:27 AM, "Adam Roach" wrote: >> >> >>> Aki Niemi [mailto:aki.niemi@nokia.com] writes: >>> >>> >>>> These are somewhat orthogonal aspects of a message session. It is >>>> probably useful to label a specific session as e.g., file-transfer >>> >>> Yes. You do this by using port 21. If you know a priori that all >>> you are going to do is transfer files, the IETF has already >>> defined a file transfer protocol. >> >> >> Yes, and FTP meets my end user to end user file transfer needs somewhat less >> well than IRC meets my IMPP needs. File transfer is a requirement for any >> viable modern IM application. FTP will still be used for places where it >> meets the needs. > > I agree that it is a requirement for any modern application. That does > not necessarily make it a requirement of a particular protocol. I know > that under certain conditions, the mechanism yahoo uses for file > transfer is very different than the mechanism it uses for IM transport. > > It would be well within reason for us to specify how to securly signal > ftp sessions via SIP. > > That all being said, we established a consensus that MSRP (Or should > that be MSP now?) was expected to be able to carry arbitrarily large > content. I very much doubt that consensus has changed. Yes - that makes sense - sorry I brought up the topic again. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 18 21:21:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01977; Tue, 18 Nov 2003 21:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMHxv-0005fq-00; Tue, 18 Nov 2003 21:21:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMHxv-0005fn-00; Tue, 18 Nov 2003 21:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMHxm-00015w-4L; Tue, 18 Nov 2003 21:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMHxe-00015i-B3 for simple@optimus.ietf.org; Tue, 18 Nov 2003 21:20:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01971 for ; Tue, 18 Nov 2003 21:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMHxb-0005fi-00 for simple@ietf.org; Tue, 18 Nov 2003 21:20:51 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AMHxa-0005fG-00 for simple@ietf.org; Tue, 18 Nov 2003 21:20:50 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 18 Nov 2003 18:20:11 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Nov 2003 18:20:27 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 Nov 2003 18:20:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOtfFis8P48dxURTSmc8PNLsA849gArDVRg From: "Orit Levin" To: X-OriginalArrivalTime: 19 Nov 2003 02:20:26.0397 (UTC) FILETIME=[B1B4E4D0:01C3AE43] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 18:20:15 -0800 Content-Transfer-Encoding: quoted-printable SIMPLE **IS** a specific application that uses SIP (with its SUBSCRIBE and NOTIFY) as a signaling infrastructure. Therefore, the question whether the ad-hoc list should be standardized in SIP as a general mechanism is an implementation issue from the SIMPLE perspective. The question is whether we need to standardize the ad-hoc list SUBSCRIBE in SIMPLE. The more general and the real question is how our SIMPLE systems are going to look like: (1)Arbitrary configuration and management protocols (XCAP as one of them) and SIP infrastructure (e.g. routing and security) for all dynamic signaling (including signaling of lists) and event reporting. (2) Arbitrary configuration and management protocols; XCAP for all dynamic application infrastructure (e.g. all the Presence lists) and SIP infrastructure for routing of events only. (3) XCAP for configuration, management and all dynamic application infrastructure (e.g. all the Presence lists) and SIP infrastructure for routing of events only. I definitely vote for option (1). For example, how are we planning to move forward and build scalable interoperable SIMPLE systems relying exclusively on XCAP?=20 Are we planning to automatically distribute the dynamic lists across the network using XCAP? Orit.=20 -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Ben Campbell Sent: Monday, November 17, 2003 6:32 PM To: Adam Roach Cc: 'Paul Kyzivat'; Markus.Isomaki@nokia.com; dean.willis@softarmor.com; Jonathan Rosenberg; simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions Adam Roach wrote: >=20 > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >=20 >>Adam Roach wrote: >> >> >>>Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>> >>> >>> >>>>[U]nless there is an agreement on how to standardize=20 >>>>servers (by name or whatever), there isn't really much need to=20 >>>>standardize *anything* about this behavior - even the name of the=20 >>>>parameter (list=3D). It perhaps just becomes some sort of best=20 >>>>practices or informational draft. >>> >>> >>>I came to the same conclusion. I think I like that fact. >>> >> >>I don't think this affects the need for standardization one way or=20 >>another. We can standardize that the R-URI designates the application=20 >>receiving the request, and leave the rest open.=20 >=20 >=20 > Isn't that precisely what RFC 3087 already says? >=20 >=20 >>But we could also decide that a particular application (e.g. >>subscribing to an add-hoc list) is sufficiently interesting when >>interoperable to standardize that application. >=20 >=20 > I could easily see a standards-track document that defines > semantics for a "list" parameter on a SIP URI (i.e. it points > to a URI that, when dereferenced, contains a list of recipients > that the application being invoked knows how to handle). Would > that accomplish what you want to do? My point was not that we need to standardize anything. It was to say=20 that deciding to structure things this way, and deciding if anything=20 needs to be standardized, are mostly orthagonal decisions. It seemed=20 like we were going down the path of saying that, if we make this=20 decision, we don't have to standardize anything. If that is a true=20 statement, then we probably didn't need to standardize anything before,=20 either. I suspect I am stating something so obvious that the act of stating it=20 causes confusion. Nevermind. >=20 > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 18 21:21:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01993 for ; Tue, 18 Nov 2003 21:21:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMHxy-00016s-RM for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 21:21:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ2LE6X004262 for simple-archive@odin.ietf.org; Tue, 18 Nov 2003 21:21:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMHxy-00016f-Mt for simple-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 21:21:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01977; Tue, 18 Nov 2003 21:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMHxv-0005fq-00; Tue, 18 Nov 2003 21:21:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMHxv-0005fn-00; Tue, 18 Nov 2003 21:21:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMHxm-00015w-4L; Tue, 18 Nov 2003 21:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMHxe-00015i-B3 for simple@optimus.ietf.org; Tue, 18 Nov 2003 21:20:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01971 for ; Tue, 18 Nov 2003 21:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMHxb-0005fi-00 for simple@ietf.org; Tue, 18 Nov 2003 21:20:51 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AMHxa-0005fG-00 for simple@ietf.org; Tue, 18 Nov 2003 21:20:50 -0500 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 18 Nov 2003 18:20:11 -0800 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Nov 2003 18:20:27 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 18 Nov 2003 18:20:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOtfFis8P48dxURTSmc8PNLsA849gArDVRg From: "Orit Levin" To: X-OriginalArrivalTime: 19 Nov 2003 02:20:26.0397 (UTC) FILETIME=[B1B4E4D0:01C3AE43] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 18 Nov 2003 18:20:15 -0800 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable SIMPLE **IS** a specific application that uses SIP (with its SUBSCRIBE and NOTIFY) as a signaling infrastructure. Therefore, the question whether the ad-hoc list should be standardized in SIP as a general mechanism is an implementation issue from the SIMPLE perspective. The question is whether we need to standardize the ad-hoc list SUBSCRIBE in SIMPLE. The more general and the real question is how our SIMPLE systems are going to look like: (1)Arbitrary configuration and management protocols (XCAP as one of them) and SIP infrastructure (e.g. routing and security) for all dynamic signaling (including signaling of lists) and event reporting. (2) Arbitrary configuration and management protocols; XCAP for all dynamic application infrastructure (e.g. all the Presence lists) and SIP infrastructure for routing of events only. (3) XCAP for configuration, management and all dynamic application infrastructure (e.g. all the Presence lists) and SIP infrastructure for routing of events only. I definitely vote for option (1). For example, how are we planning to move forward and build scalable interoperable SIMPLE systems relying exclusively on XCAP?=20 Are we planning to automatically distribute the dynamic lists across the network using XCAP? Orit.=20 -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Ben Campbell Sent: Monday, November 17, 2003 6:32 PM To: Adam Roach Cc: 'Paul Kyzivat'; Markus.Isomaki@nokia.com; dean.willis@softarmor.com; Jonathan Rosenberg; simple@ietf.org Subject: Re: [Simple] ad-hoc list subscriptions Adam Roach wrote: >=20 > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >=20 >>Adam Roach wrote: >> >> >>>Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>> >>> >>> >>>>[U]nless there is an agreement on how to standardize=20 >>>>servers (by name or whatever), there isn't really much need to=20 >>>>standardize *anything* about this behavior - even the name of the=20 >>>>parameter (list=3D). It perhaps just becomes some sort of best=20 >>>>practices or informational draft. >>> >>> >>>I came to the same conclusion. I think I like that fact. >>> >> >>I don't think this affects the need for standardization one way or=20 >>another. We can standardize that the R-URI designates the application=20 >>receiving the request, and leave the rest open.=20 >=20 >=20 > Isn't that precisely what RFC 3087 already says? >=20 >=20 >>But we could also decide that a particular application (e.g. >>subscribing to an add-hoc list) is sufficiently interesting when >>interoperable to standardize that application. >=20 >=20 > I could easily see a standards-track document that defines > semantics for a "list" parameter on a SIP URI (i.e. it points > to a URI that, when dereferenced, contains a list of recipients > that the application being invoked knows how to handle). Would > that accomplish what you want to do? My point was not that we need to standardize anything. It was to say=20 that deciding to structure things this way, and deciding if anything=20 needs to be standardized, are mostly orthagonal decisions. It seemed=20 like we were going down the path of saying that, if we make this=20 decision, we don't have to standardize anything. If that is a true=20 statement, then we probably didn't need to standardize anything before,=20 either. I suspect I am stating something so obvious that the act of stating it=20 causes confusion. Nevermind. >=20 > /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 06:13:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12648; Wed, 19 Nov 2003 06:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQHZ-00052i-00; Wed, 19 Nov 2003 06:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMQHZ-00052f-00; Wed, 19 Nov 2003 06:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQHZ-0002Pf-Eu; Wed, 19 Nov 2003 06:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQH9-0002PE-Vm for simple@optimus.ietf.org; Wed, 19 Nov 2003 06:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12623 for ; Wed, 19 Nov 2003 06:13:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQH5-000527-00 for simple@ietf.org; Wed, 19 Nov 2003 06:13:31 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMQH5-000524-00 for simple@ietf.org; Wed, 19 Nov 2003 06:13:31 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJBDVA10864 for ; Wed, 19 Nov 2003 13:13:31 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 13:13:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 13:13:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Objects to NATs kill TCP connection Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973EB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Objects to NATs kill TCP connection Thread-Index: AcOuCFBoPj74gUbOQtSvV6UvBOA5eAAhX+Tg To: , Cc: , , X-OriginalArrivalTime: 19 Nov 2003 11:13:29.0145 (UTC) FILETIME=[28E8F290:01C3AE8E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 13:13:28 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 18.November.2003 21:13 > To: Ben Campbell > Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org > Subject: Re: [Simple] Objects to NATs kill TCP connection >=20 >=20 >=20 >=20 > Ben Campbell wrote: > > Can we reasonably assume that all connection failures are=20 > due to NATs?=20 > > What happens if endpoints do this when the failure is caused by=20 > > something else? >=20 > Good point. That could be ugly - I don't see any easy way to=20 > know when=20 > the connection fails because of NAT. Lacking that it seems=20 > infeasible to=20 > test for the NAT timeout interval. >=20 > Are there any standard practices in this regard? In other words, is=20 > there a keepalive time we could use that would be sufficient=20 > most of the=20 > time and still not be too impractical to keep up? To be safe, you need a keepalive message every 30 seconds. You can = always send empty TCP packets. Shouldn't this anyway be a relay problem? maybe a BIND is sent to the = relay every x seconds. Regards, Hisham >=20 > Paul >=20 > > Paul Kyzivat wrote: > >=20 > >> Letting msrp keepalives act as NAT binding keepalives seems=20 > >> attractive. Perhaps the NAT keepalive time needs to be determined=20 > >> adaptively. If the connection is found to be down, a=20 > reinvite could=20 > >> reconstruct it, and a new keepalive timer could be set,=20 > shorter than=20 > >> before. > >> > >> But this would require negotiating the keepalive time. > >> > >> Paul > >> > >> Jonathan Rosenberg wrote: > >> > >>> The trick, as always, is knowing what the nat keepalive=20 > is. There is=20 > >>> no easy way to know. > >>> > >>> -Jonathan R. > >>> > >>> Ben Campbell wrote: > >>> > >>>> When we were having the recent discussion on the=20 > inactivity timeout=20 > >>>> for MS(R)P, I don't think we thought much about the fact=20 > that MSRP=20 > >>>> keepalive messages may also act as NAT binding keepalives. > >>>> > >>>> > >>>> > >>>> Jonathan Rosenberg wrote: > >>>> > >>>>> Short timeouts are broken, sure, but the fact that NATs have=20 > >>>>> timeouts on bindings is a common behavior. As a result,=20 > if there is=20 > >>>>> no traffic on the TCP connection before the timeout occurs, the=20 > >>>>> binding is lost, and any data sent on that connection will fail. > >>>>> > >>>>> Therefore, I think we can expect to see cases where the=20 > connections=20 > >>>>> close due to NAT. > >>>>> > >>>>> Now, the question is, do we think we would see periods of=20 > >>>>> inactivity on the messaging will exceed a typical nat=20 > timeout? I=20 > >>>>> think they may. I personally tend to leave IM sessions open=20 > >>>>> continuously all day.. > >>>>> > >>>>> -Jonathan R. > >>>>> > >>>>> Ben Campbell wrote: > >>>>> > >>>>>> I have personally encountered this behavior in the=20 > wild. I agree,=20 > >>>>>> however, that it was broken, and probably not a normal=20 > use case.=20 > >>>>>> And as far as I know, it pretty much killed anything=20 > other than=20 > >>>>>> hit-and-run HTTP connections. > >>>>>> > >>>>>> Paul Kyzivat wrote: > >>>>>> > >>>>>>> Cullen, > >>>>>>> > >>>>>>> I don't have any data of my own on this subject, but=20 > I hope you=20 > >>>>>>> are right. > >>>>>>> > >>>>>>> It would be a lot simpler if we can continue to=20 > assume that the=20 > >>>>>>> way you reestablish an MSRP session is via a reINVITE. The=20 > >>>>>>> adequacy of that was under question if NATs regularly=20 > blow away=20 > >>>>>>> connections. > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>> Cullen Jennings wrote: > >>>>>>> > >>>>>>>> There was some assertion in the WG meeting that NATs=20 > arbitrarily=20 > >>>>>>>> kill TCP > >>>>>>>> connection and the connection needs to be set up=20 > again. I'm sure=20 > >>>>>>>> this has > >>>>>>>> happened with broken NATS but I do not feel it is=20 > widespread and=20 > >>>>>>>> don't think > >>>>>>>> we should specifically design for it. I do think we should=20 > >>>>>>>> design for > >>>>>>>> graceful failure or recover when things in the=20 > network fail but=20 > >>>>>>>> I don't > >>>>>>>> think there is a common case of TCP failing that=20 > involves NATs.=20 > >>>>>>>> If there > >>>>>>>> were, many things that do not automatically set up a new TCP=20 > >>>>>>>> connection, > >>>>>>>> like ssh for example, would be nearly unusable through these=20 > >>>>>>>> broken NATs. > >>>>>>>> > >>>>>>>> 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 > >>>>>> > >>>>> > >>>> > >>>> > >>> > >=20 > >=20 > >=20 >=20 >=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 exim@www1.ietf.org Wed Nov 19 06:14:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12671 for ; Wed, 19 Nov 2003 06:14:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQHe-0002QU-GN for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 06:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJBE6Hq009322 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 06:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQHe-0002QH-CA for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 06:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12648; Wed, 19 Nov 2003 06:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQHZ-00052i-00; Wed, 19 Nov 2003 06:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMQHZ-00052f-00; Wed, 19 Nov 2003 06:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQHZ-0002Pf-Eu; Wed, 19 Nov 2003 06:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMQH9-0002PE-Vm for simple@optimus.ietf.org; Wed, 19 Nov 2003 06:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12623 for ; Wed, 19 Nov 2003 06:13:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMQH5-000527-00 for simple@ietf.org; Wed, 19 Nov 2003 06:13:31 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AMQH5-000524-00 for simple@ietf.org; Wed, 19 Nov 2003 06:13:31 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAJBDVA10864 for ; Wed, 19 Nov 2003 13:13:31 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 19 Nov 2003 13:13:29 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 19 Nov 2003 13:13:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Objects to NATs kill TCP connection Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973EB@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Objects to NATs kill TCP connection Thread-Index: AcOuCFBoPj74gUbOQtSvV6UvBOA5eAAhX+Tg To: , Cc: , , X-OriginalArrivalTime: 19 Nov 2003 11:13:29.0145 (UTC) FILETIME=[28E8F290:01C3AE8E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 13:13:28 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Paul Kyzivat > Sent: 18.November.2003 21:13 > To: Ben Campbell > Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org > Subject: Re: [Simple] Objects to NATs kill TCP connection >=20 >=20 >=20 >=20 > Ben Campbell wrote: > > Can we reasonably assume that all connection failures are=20 > due to NATs?=20 > > What happens if endpoints do this when the failure is caused by=20 > > something else? >=20 > Good point. That could be ugly - I don't see any easy way to=20 > know when=20 > the connection fails because of NAT. Lacking that it seems=20 > infeasible to=20 > test for the NAT timeout interval. >=20 > Are there any standard practices in this regard? In other words, is=20 > there a keepalive time we could use that would be sufficient=20 > most of the=20 > time and still not be too impractical to keep up? To be safe, you need a keepalive message every 30 seconds. You can = always send empty TCP packets. Shouldn't this anyway be a relay problem? maybe a BIND is sent to the = relay every x seconds. Regards, Hisham >=20 > Paul >=20 > > Paul Kyzivat wrote: > >=20 > >> Letting msrp keepalives act as NAT binding keepalives seems=20 > >> attractive. Perhaps the NAT keepalive time needs to be determined=20 > >> adaptively. If the connection is found to be down, a=20 > reinvite could=20 > >> reconstruct it, and a new keepalive timer could be set,=20 > shorter than=20 > >> before. > >> > >> But this would require negotiating the keepalive time. > >> > >> Paul > >> > >> Jonathan Rosenberg wrote: > >> > >>> The trick, as always, is knowing what the nat keepalive=20 > is. There is=20 > >>> no easy way to know. > >>> > >>> -Jonathan R. > >>> > >>> Ben Campbell wrote: > >>> > >>>> When we were having the recent discussion on the=20 > inactivity timeout=20 > >>>> for MS(R)P, I don't think we thought much about the fact=20 > that MSRP=20 > >>>> keepalive messages may also act as NAT binding keepalives. > >>>> > >>>> > >>>> > >>>> Jonathan Rosenberg wrote: > >>>> > >>>>> Short timeouts are broken, sure, but the fact that NATs have=20 > >>>>> timeouts on bindings is a common behavior. As a result,=20 > if there is=20 > >>>>> no traffic on the TCP connection before the timeout occurs, the=20 > >>>>> binding is lost, and any data sent on that connection will fail. > >>>>> > >>>>> Therefore, I think we can expect to see cases where the=20 > connections=20 > >>>>> close due to NAT. > >>>>> > >>>>> Now, the question is, do we think we would see periods of=20 > >>>>> inactivity on the messaging will exceed a typical nat=20 > timeout? I=20 > >>>>> think they may. I personally tend to leave IM sessions open=20 > >>>>> continuously all day.. > >>>>> > >>>>> -Jonathan R. > >>>>> > >>>>> Ben Campbell wrote: > >>>>> > >>>>>> I have personally encountered this behavior in the=20 > wild. I agree,=20 > >>>>>> however, that it was broken, and probably not a normal=20 > use case.=20 > >>>>>> And as far as I know, it pretty much killed anything=20 > other than=20 > >>>>>> hit-and-run HTTP connections. > >>>>>> > >>>>>> Paul Kyzivat wrote: > >>>>>> > >>>>>>> Cullen, > >>>>>>> > >>>>>>> I don't have any data of my own on this subject, but=20 > I hope you=20 > >>>>>>> are right. > >>>>>>> > >>>>>>> It would be a lot simpler if we can continue to=20 > assume that the=20 > >>>>>>> way you reestablish an MSRP session is via a reINVITE. The=20 > >>>>>>> adequacy of that was under question if NATs regularly=20 > blow away=20 > >>>>>>> connections. > >>>>>>> > >>>>>>> Paul > >>>>>>> > >>>>>>> Cullen Jennings wrote: > >>>>>>> > >>>>>>>> There was some assertion in the WG meeting that NATs=20 > arbitrarily=20 > >>>>>>>> kill TCP > >>>>>>>> connection and the connection needs to be set up=20 > again. I'm sure=20 > >>>>>>>> this has > >>>>>>>> happened with broken NATS but I do not feel it is=20 > widespread and=20 > >>>>>>>> don't think > >>>>>>>> we should specifically design for it. I do think we should=20 > >>>>>>>> design for > >>>>>>>> graceful failure or recover when things in the=20 > network fail but=20 > >>>>>>>> I don't > >>>>>>>> think there is a common case of TCP failing that=20 > involves NATs.=20 > >>>>>>>> If there > >>>>>>>> were, many things that do not automatically set up a new TCP=20 > >>>>>>>> connection, > >>>>>>>> like ssh for example, would be nearly unusable through these=20 > >>>>>>>> broken NATs. > >>>>>>>> > >>>>>>>> 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 > >>>>>> > >>>>> > >>>> > >>>> > >>> > >=20 > >=20 > >=20 >=20 >=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-admin@ietf.org Wed Nov 19 09:23:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17577; Wed, 19 Nov 2003 09:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTFU-0007ia-00; Wed, 19 Nov 2003 09:24:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTFT-0007iX-00; Wed, 19 Nov 2003 09:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTFQ-00045Q-Vu; Wed, 19 Nov 2003 09:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTEt-000457-SH for simple@optimus.ietf.org; Wed, 19 Nov 2003 09:23:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17573 for ; Wed, 19 Nov 2003 09:23:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTEs-0007iP-00 for simple@ietf.org; Wed, 19 Nov 2003 09:23:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMTEr-0007iM-00 for simple@ietf.org; Wed, 19 Nov 2003 09:23:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAJEN5nG046050; Wed, 19 Nov 2003 08:23:17 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBB7CC4.6020500@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, jdrosen@dynamicsoft.com, fluffy@cisco.com, simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <2038BCC78B1AD641891A0D1AE133DBB7017973EB@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973EB@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 08:23:00 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Paul Kyzivat >>Sent: 18.November.2003 21:13 >>To: Ben Campbell >>Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org >>Subject: Re: [Simple] Objects to NATs kill TCP connection >> >> >> >> >>Ben Campbell wrote: >> >>>Can we reasonably assume that all connection failures are >> >>due to NATs? >> >>>What happens if endpoints do this when the failure is caused by >>>something else? >> >>Good point. That could be ugly - I don't see any easy way to >>know when >>the connection fails because of NAT. Lacking that it seems >>infeasible to >>test for the NAT timeout interval. >> >>Are there any standard practices in this regard? In other words, is >>there a keepalive time we could use that would be sufficient >>most of the >>time and still not be too impractical to keep up? > > > To be safe, you need a keepalive message every 30 seconds. You can always send empty TCP packets. > > Shouldn't this anyway be a relay problem? maybe a BIND is sent to the relay every x seconds. It can occur without any relays. For example, what if one (the active) endpoint is natted and the other is not? This scenario works with no relays. > > Regards, > Hisham > > >> Paul >> >> >>>Paul Kyzivat wrote: >>> >>> >>>>Letting msrp keepalives act as NAT binding keepalives seems >>>>attractive. Perhaps the NAT keepalive time needs to be determined >>>>adaptively. If the connection is found to be down, a >> >>reinvite could >> >>>>reconstruct it, and a new keepalive timer could be set, >> >>shorter than >> >>>>before. >>>> >>>>But this would require negotiating the keepalive time. >>>> >>>> Paul >>>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>>>The trick, as always, is knowing what the nat keepalive >> >>is. There is >> >>>>>no easy way to know. >>>>> >>>>>-Jonathan R. >>>>> >>>>>Ben Campbell wrote: >>>>> >>>>> >>>>>>When we were having the recent discussion on the >> >>inactivity timeout >> >>>>>>for MS(R)P, I don't think we thought much about the fact >> >>that MSRP >> >>>>>>keepalive messages may also act as NAT binding keepalives. >>>>>> >>>>>> >>>>>> >>>>>>Jonathan Rosenberg wrote: >>>>>> >>>>>> >>>>>>>Short timeouts are broken, sure, but the fact that NATs have >>>>>>>timeouts on bindings is a common behavior. As a result, >> >>if there is >> >>>>>>>no traffic on the TCP connection before the timeout occurs, the >>>>>>>binding is lost, and any data sent on that connection will fail. >>>>>>> >>>>>>>Therefore, I think we can expect to see cases where the >> >>connections >> >>>>>>>close due to NAT. >>>>>>> >>>>>>>Now, the question is, do we think we would see periods of >>>>>>>inactivity on the messaging will exceed a typical nat >> >>timeout? I >> >>>>>>>think they may. I personally tend to leave IM sessions open >>>>>>>continuously all day.. >>>>>>> >>>>>>>-Jonathan R. >>>>>>> >>>>>>>Ben Campbell wrote: >>>>>>> >>>>>>> >>>>>>>>I have personally encountered this behavior in the >> >>wild. I agree, >> >>>>>>>>however, that it was broken, and probably not a normal >> >>use case. >> >>>>>>>>And as far as I know, it pretty much killed anything >> >>other than >> >>>>>>>>hit-and-run HTTP connections. >>>>>>>> >>>>>>>>Paul Kyzivat wrote: >>>>>>>> >>>>>>>> >>>>>>>>>Cullen, >>>>>>>>> >>>>>>>>>I don't have any data of my own on this subject, but >> >>I hope you >> >>>>>>>>>are right. >>>>>>>>> >>>>>>>>>It would be a lot simpler if we can continue to >> >>assume that the >> >>>>>>>>>way you reestablish an MSRP session is via a reINVITE. The >>>>>>>>>adequacy of that was under question if NATs regularly >> >>blow away >> >>>>>>>>>connections. >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>Cullen Jennings wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>There was some assertion in the WG meeting that NATs >> >>arbitrarily >> >>>>>>>>>>kill TCP >>>>>>>>>>connection and the connection needs to be set up >> >>again. I'm sure >> >>>>>>>>>>this has >>>>>>>>>>happened with broken NATS but I do not feel it is >> >>widespread and >> >>>>>>>>>>don't think >>>>>>>>>>we should specifically design for it. I do think we should >>>>>>>>>>design for >>>>>>>>>>graceful failure or recover when things in the >> >>network fail but >> >>>>>>>>>>I don't >>>>>>>>>>think there is a common case of TCP failing that >> >>involves NATs. >> >>>>>>>>>>If there >>>>>>>>>>were, many things that do not automatically set up a new TCP >>>>>>>>>>connection, >>>>>>>>>>like ssh for example, would be nearly unusable through these >>>>>>>>>>broken NATs. >>>>>>>>>> >>>>>>>>>>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 >>>>>>>> >>>>>>> >>>>>> >>> >>> >> >>_______________________________________________ >>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 exim@www1.ietf.org Wed Nov 19 09:24:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17601 for ; Wed, 19 Nov 2003 09:24:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTFW-00046K-J2 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 09:24:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJEO6ZR015758 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 09:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTFW-000465-Fj for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 09:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17577; Wed, 19 Nov 2003 09:23:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTFU-0007ia-00; Wed, 19 Nov 2003 09:24:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMTFT-0007iX-00; Wed, 19 Nov 2003 09:24:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTFQ-00045Q-Vu; Wed, 19 Nov 2003 09:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMTEt-000457-SH for simple@optimus.ietf.org; Wed, 19 Nov 2003 09:23:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17573 for ; Wed, 19 Nov 2003 09:23:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMTEs-0007iP-00 for simple@ietf.org; Wed, 19 Nov 2003 09:23:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMTEr-0007iM-00 for simple@ietf.org; Wed, 19 Nov 2003 09:23:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAJEN5nG046050; Wed, 19 Nov 2003 08:23:17 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBB7CC4.6020500@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, jdrosen@dynamicsoft.com, fluffy@cisco.com, simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <2038BCC78B1AD641891A0D1AE133DBB7017973EB@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973EB@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 08:23:00 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Paul Kyzivat >>Sent: 18.November.2003 21:13 >>To: Ben Campbell >>Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org >>Subject: Re: [Simple] Objects to NATs kill TCP connection >> >> >> >> >>Ben Campbell wrote: >> >>>Can we reasonably assume that all connection failures are >> >>due to NATs? >> >>>What happens if endpoints do this when the failure is caused by >>>something else? >> >>Good point. That could be ugly - I don't see any easy way to >>know when >>the connection fails because of NAT. Lacking that it seems >>infeasible to >>test for the NAT timeout interval. >> >>Are there any standard practices in this regard? In other words, is >>there a keepalive time we could use that would be sufficient >>most of the >>time and still not be too impractical to keep up? > > > To be safe, you need a keepalive message every 30 seconds. You can always send empty TCP packets. > > Shouldn't this anyway be a relay problem? maybe a BIND is sent to the relay every x seconds. It can occur without any relays. For example, what if one (the active) endpoint is natted and the other is not? This scenario works with no relays. > > Regards, > Hisham > > >> Paul >> >> >>>Paul Kyzivat wrote: >>> >>> >>>>Letting msrp keepalives act as NAT binding keepalives seems >>>>attractive. Perhaps the NAT keepalive time needs to be determined >>>>adaptively. If the connection is found to be down, a >> >>reinvite could >> >>>>reconstruct it, and a new keepalive timer could be set, >> >>shorter than >> >>>>before. >>>> >>>>But this would require negotiating the keepalive time. >>>> >>>> Paul >>>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>>>The trick, as always, is knowing what the nat keepalive >> >>is. There is >> >>>>>no easy way to know. >>>>> >>>>>-Jonathan R. >>>>> >>>>>Ben Campbell wrote: >>>>> >>>>> >>>>>>When we were having the recent discussion on the >> >>inactivity timeout >> >>>>>>for MS(R)P, I don't think we thought much about the fact >> >>that MSRP >> >>>>>>keepalive messages may also act as NAT binding keepalives. >>>>>> >>>>>> >>>>>> >>>>>>Jonathan Rosenberg wrote: >>>>>> >>>>>> >>>>>>>Short timeouts are broken, sure, but the fact that NATs have >>>>>>>timeouts on bindings is a common behavior. As a result, >> >>if there is >> >>>>>>>no traffic on the TCP connection before the timeout occurs, the >>>>>>>binding is lost, and any data sent on that connection will fail. >>>>>>> >>>>>>>Therefore, I think we can expect to see cases where the >> >>connections >> >>>>>>>close due to NAT. >>>>>>> >>>>>>>Now, the question is, do we think we would see periods of >>>>>>>inactivity on the messaging will exceed a typical nat >> >>timeout? I >> >>>>>>>think they may. I personally tend to leave IM sessions open >>>>>>>continuously all day.. >>>>>>> >>>>>>>-Jonathan R. >>>>>>> >>>>>>>Ben Campbell wrote: >>>>>>> >>>>>>> >>>>>>>>I have personally encountered this behavior in the >> >>wild. I agree, >> >>>>>>>>however, that it was broken, and probably not a normal >> >>use case. >> >>>>>>>>And as far as I know, it pretty much killed anything >> >>other than >> >>>>>>>>hit-and-run HTTP connections. >>>>>>>> >>>>>>>>Paul Kyzivat wrote: >>>>>>>> >>>>>>>> >>>>>>>>>Cullen, >>>>>>>>> >>>>>>>>>I don't have any data of my own on this subject, but >> >>I hope you >> >>>>>>>>>are right. >>>>>>>>> >>>>>>>>>It would be a lot simpler if we can continue to >> >>assume that the >> >>>>>>>>>way you reestablish an MSRP session is via a reINVITE. The >>>>>>>>>adequacy of that was under question if NATs regularly >> >>blow away >> >>>>>>>>>connections. >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>>Cullen Jennings wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>There was some assertion in the WG meeting that NATs >> >>arbitrarily >> >>>>>>>>>>kill TCP >>>>>>>>>>connection and the connection needs to be set up >> >>again. I'm sure >> >>>>>>>>>>this has >>>>>>>>>>happened with broken NATS but I do not feel it is >> >>widespread and >> >>>>>>>>>>don't think >>>>>>>>>>we should specifically design for it. I do think we should >>>>>>>>>>design for >>>>>>>>>>graceful failure or recover when things in the >> >>network fail but >> >>>>>>>>>>I don't >>>>>>>>>>think there is a common case of TCP failing that >> >>involves NATs. >> >>>>>>>>>>If there >>>>>>>>>>were, many things that do not automatically set up a new TCP >>>>>>>>>>connection, >>>>>>>>>>like ssh for example, would be nearly unusable through these >>>>>>>>>>broken NATs. >>>>>>>>>> >>>>>>>>>>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 >>>>>>>> >>>>>>> >>>>>> >>> >>> >> >>_______________________________________________ >>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-admin@ietf.org Wed Nov 19 11:36:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25061; Wed, 19 Nov 2003 11:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVKD-0002aO-00; Wed, 19 Nov 2003 11:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVKD-0002aI-00; Wed, 19 Nov 2003 11:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVK9-0005Ev-Ho; Wed, 19 Nov 2003 11:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVJd-0005Dt-4n for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:36:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25050 for ; Wed, 19 Nov 2003 11:36:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVJc-0002Zn-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:28 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMVJb-0002ZM-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:27 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGZsAt007608; Wed, 19 Nov 2003 08:35:55 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB91390; Wed, 19 Nov 2003 08:35:53 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP Open Issues From: Cullen Jennings To: "Miguel A. Garcia" , Ben Campbell CC: Simple WG Message-ID: In-Reply-To: <3FBA452B.9070307@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 07:14:48 -0800 Content-Transfer-Encoding: 7bit On 11/18/03 8:13 AM, "Miguel A. Garcia" wrote: > Ben Campbell wrote: > >> >> 5. Generalize MIME handling to include mime version and allow arbitrary >> MIME headers. >> > > Will this include the possibility of sending all the Content-* headers > in MSRP. So far the draft only includes Content-Type, but I believe > other Content-* headers will be useful (e.g., Content-Transfer-Encoding > or Content-Disposition). > > /Miguel I think Content-Transfer-Encoding and Content-Disposition are a good idea but, since this is a 8bit safe system, I think we should say things SHOULD be sent with a Content-Transfer-Encoding of binary and all the examples should show this. This caused many interoperability headaches in page mode. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 11:36:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25069; Wed, 19 Nov 2003 11:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVKE-0002aj-00; Wed, 19 Nov 2003 11:37:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVKE-0002aH-00; Wed, 19 Nov 2003 11:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVK9-0005En-3r; Wed, 19 Nov 2003 11:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVJc-0005Do-Bc for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25047 for ; Wed, 19 Nov 2003 11:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVJb-0002Zi-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:27 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMVJa-0002ZG-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2003 08:36:06 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGZrAt007591; Wed, 19 Nov 2003 08:35:54 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB91388; Wed, 19 Nov 2003 08:35:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) From: Cullen Jennings To: Adam Roach , Ben Campbell CC: Paul Kyzivat , , Dean Willis , Jonathan Rosenberg , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 07:10:50 -0800 Content-Transfer-Encoding: 7bit Several people have mentioned my previous VM-URI draft demonstrated a completely lack of understanding of 3087 on my part. This is true - I don't think I fully get what is says. So help me understand in context of this ad-hoc subscription stuff.... I think you are suggesting that Customer A might configure their phones and proxies to use a URI like fluffy%40cisco.com+rohan%40cisco.com@example.com Customer B might configure them to be fluff_at_cisco.com_and_rohan_at_cisco.com@example.com Customer C might use fluffy%40cisco.com;rohan%40cisco.com@example.com Customer D might use exploder:to=fluffy%40cisco.com:to=rohan%40cisco.com@example.com And the proxies and UA are coning to be arbitrarily configurable to support all of these in a way that the administrator understands even when they all come from different vendors. Just look a the problems caused by configuring the most trivial of dial plans in phones today. I really hope this is not what 3087 recommended, because if it does, I suspect it will never pass the running code test. Can you imagine what the manual for the proxy would like that explained to some network administrator how to do this, It's just not practical. What about a phone that formed composites sets of names differently depending on where it was going to request the same service from. If you think the ad-hoc lists or exploders idea is useful, then we should work out a convention for doing it. I don't care if it is in a body, header, or URI. On 11/17/03 4:57 PM, "Adam Roach" wrote: > > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >> Adam Roach wrote: >> >>> Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>> >>> >>>> [U]nless there is an agreement on how to standardize >>>> servers (by name or whatever), there isn't really much need to >>>> standardize *anything* about this behavior - even the name of the >>>> parameter (list=). It perhaps just becomes some sort of best >>>> practices or informational draft. >>> >>> >>> I came to the same conclusion. I think I like that fact. >>> >> >> I don't think this affects the need for standardization one way or >> another. We can standardize that the R-URI designates the application >> receiving the request, and leave the rest open. > > Isn't that precisely what RFC 3087 already says? > >> But we could also decide that a particular application (e.g. >> subscribing to an add-hoc list) is sufficiently interesting when >> interoperable to standardize that application. > > I could easily see a standards-track document that defines > semantics for a "list" parameter on a SIP URI (i.e. it points > to a URI that, when dereferenced, contains a list of recipients > that the application being invoked knows how to handle). Would > that accomplish what you want to do? > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 11:37:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25116 for ; Wed, 19 Nov 2003 11:37:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVKG-0005IZ-Hm for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGb87a020357 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVKG-0005IB-7w for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25061; Wed, 19 Nov 2003 11:36:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVKD-0002aO-00; Wed, 19 Nov 2003 11:37:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVKD-0002aI-00; Wed, 19 Nov 2003 11:37:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVK9-0005Ev-Ho; Wed, 19 Nov 2003 11:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVJd-0005Dt-4n for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:36:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25050 for ; Wed, 19 Nov 2003 11:36:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVJc-0002Zn-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:28 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMVJb-0002ZM-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:27 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGZsAt007608; Wed, 19 Nov 2003 08:35:55 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB91390; Wed, 19 Nov 2003 08:35:53 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MSRP Open Issues From: Cullen Jennings To: "Miguel A. Garcia" , Ben Campbell CC: Simple WG Message-ID: In-Reply-To: <3FBA452B.9070307@ericsson.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 07:14:48 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/18/03 8:13 AM, "Miguel A. Garcia" wrote: > Ben Campbell wrote: > >> >> 5. Generalize MIME handling to include mime version and allow arbitrary >> MIME headers. >> > > Will this include the possibility of sending all the Content-* headers > in MSRP. So far the draft only includes Content-Type, but I believe > other Content-* headers will be useful (e.g., Content-Transfer-Encoding > or Content-Disposition). > > /Miguel I think Content-Transfer-Encoding and Content-Disposition are a good idea but, since this is a 8bit safe system, I think we should say things SHOULD be sent with a Content-Transfer-Encoding of binary and all the examples should show this. This caused many interoperability headaches in page mode. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 11:37:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25131 for ; Wed, 19 Nov 2003 11:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVKG-0005Iw-TW for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:37:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGb8aT020378 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:37:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVKG-0005IY-Hd for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25069; Wed, 19 Nov 2003 11:36:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVKE-0002aj-00; Wed, 19 Nov 2003 11:37:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVKE-0002aH-00; Wed, 19 Nov 2003 11:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVK9-0005En-3r; Wed, 19 Nov 2003 11:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVJc-0005Do-Bc for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:36:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25047 for ; Wed, 19 Nov 2003 11:36:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVJb-0002Zi-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:27 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMVJa-0002ZG-00 for simple@ietf.org; Wed, 19 Nov 2003 11:36:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2003 08:36:06 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAJGZrAt007591; Wed, 19 Nov 2003 08:35:54 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB91388; Wed, 19 Nov 2003 08:35:52 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) From: Cullen Jennings To: Adam Roach , Ben Campbell CC: Paul Kyzivat , , Dean Willis , Jonathan Rosenberg , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86624@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 07:10:50 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Several people have mentioned my previous VM-URI draft demonstrated a completely lack of understanding of 3087 on my part. This is true - I don't think I fully get what is says. So help me understand in context of this ad-hoc subscription stuff.... I think you are suggesting that Customer A might configure their phones and proxies to use a URI like fluffy%40cisco.com+rohan%40cisco.com@example.com Customer B might configure them to be fluff_at_cisco.com_and_rohan_at_cisco.com@example.com Customer C might use fluffy%40cisco.com;rohan%40cisco.com@example.com Customer D might use exploder:to=fluffy%40cisco.com:to=rohan%40cisco.com@example.com And the proxies and UA are coning to be arbitrarily configurable to support all of these in a way that the administrator understands even when they all come from different vendors. Just look a the problems caused by configuring the most trivial of dial plans in phones today. I really hope this is not what 3087 recommended, because if it does, I suspect it will never pass the running code test. Can you imagine what the manual for the proxy would like that explained to some network administrator how to do this, It's just not practical. What about a phone that formed composites sets of names differently depending on where it was going to request the same service from. If you think the ad-hoc lists or exploders idea is useful, then we should work out a convention for doing it. I don't care if it is in a body, header, or URI. On 11/17/03 4:57 PM, "Adam Roach" wrote: > > > Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >> Adam Roach wrote: >> >>> Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>> >>> >>>> [U]nless there is an agreement on how to standardize >>>> servers (by name or whatever), there isn't really much need to >>>> standardize *anything* about this behavior - even the name of the >>>> parameter (list=). It perhaps just becomes some sort of best >>>> practices or informational draft. >>> >>> >>> I came to the same conclusion. I think I like that fact. >>> >> >> I don't think this affects the need for standardization one way or >> another. We can standardize that the R-URI designates the application >> receiving the request, and leave the rest open. > > Isn't that precisely what RFC 3087 already says? > >> But we could also decide that a particular application (e.g. >> subscribing to an add-hoc list) is sufficiently interesting when >> interoperable to standardize that application. > > I could easily see a standards-track document that defines > semantics for a "list" parameter on a SIP URI (i.e. it points > to a URI that, when dereferenced, contains a list of recipients > that the application being invoked knows how to handle). Would > that accomplish what you want to do? > > /a > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 11:41:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25378; Wed, 19 Nov 2003 11:41:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVP2-0002i2-00; Wed, 19 Nov 2003 11:42:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVP1-0002hz-00; Wed, 19 Nov 2003 11:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVOy-0006AF-S3; Wed, 19 Nov 2003 11:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVOK-00069a-W8 for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:41:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25344 for ; Wed, 19 Nov 2003 11:41:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVOJ-0002gp-00 for simple@ietf.org; Wed, 19 Nov 2003 11:41:19 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AMVOJ-0002gl-00 for simple@ietf.org; Wed, 19 Nov 2003 11:41:19 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAJGe6I2017382; Wed, 19 Nov 2003 17:40:07 +0100 (MET) Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.119]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id X16V1227; Wed, 19 Nov 2003 17:39:47 +0100 Message-ID: <3FBB9CE6.70204@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Cullen Jennings CC: Ben Campbell , Simple WG Subject: Re: [Simple] MSRP Open Issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 18:40:06 +0200 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I think Content-Transfer-Encoding and Content-Disposition are a good idea > but, since this is a 8bit safe system, I think we should say things SHOULD > be sent with a Content-Transfer-Encoding of binary and all the examples > should show this. This caused many interoperability headaches in page mode. > Agree. Further more, I wouldn't mind if the spec says that the default transfer encoding is binary in the absence of the Content-Transfer-Encoding. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 11:42:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25439 for ; Wed, 19 Nov 2003 11:42:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVP3-0006Eu-Sn for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:42:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGg5Zi023929 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:42:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVP3-0006Ds-KG for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:42:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25378; Wed, 19 Nov 2003 11:41:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVP2-0002i2-00; Wed, 19 Nov 2003 11:42:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVP1-0002hz-00; Wed, 19 Nov 2003 11:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVOy-0006AF-S3; Wed, 19 Nov 2003 11:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVOK-00069a-W8 for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:41:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25344 for ; Wed, 19 Nov 2003 11:41:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVOJ-0002gp-00 for simple@ietf.org; Wed, 19 Nov 2003 11:41:19 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AMVOJ-0002gl-00 for simple@ietf.org; Wed, 19 Nov 2003 11:41:19 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAJGe6I2017382; Wed, 19 Nov 2003 17:40:07 +0100 (MET) Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.119]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id X16V1227; Wed, 19 Nov 2003 17:39:47 +0100 Message-ID: <3FBB9CE6.70204@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Cullen Jennings CC: Ben Campbell , Simple WG Subject: Re: [Simple] MSRP Open Issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 18:40:06 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > I think Content-Transfer-Encoding and Content-Disposition are a good idea > but, since this is a 8bit safe system, I think we should say things SHOULD > be sent with a Content-Transfer-Encoding of binary and all the examples > should show this. This caused many interoperability headaches in page mode. > Agree. Further more, I wouldn't mind if the spec says that the default transfer encoding is binary in the absence of the Content-Transfer-Encoding. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 11:57:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26608; Wed, 19 Nov 2003 11:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVeZ-0003DP-00; Wed, 19 Nov 2003 11:58:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVeZ-0003DM-00; Wed, 19 Nov 2003 11:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVeT-0007D2-KA; Wed, 19 Nov 2003 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVdb-0007Bb-HC for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26536 for ; Wed, 19 Nov 2003 11:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVdW-0003BA-00 for simple@ietf.org; Wed, 19 Nov 2003 11:57:02 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMVdW-0003B7-00 for simple@ietf.org; Wed, 19 Nov 2003 11:57:02 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAJGtZnG059727; Wed, 19 Nov 2003 10:55:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBBA080.4070904@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Cullen Jennings , Simple WG Subject: Re: [Simple] MSRP Open Issues References: <3FBB9CE6.70204@ericsson.com> In-Reply-To: <3FBB9CE6.70204@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 10:55:28 -0600 Content-Transfer-Encoding: 7bit Agreed on both points. Miguel A. Garcia wrote: > Cullen Jennings wrote: > >> >> I think Content-Transfer-Encoding and Content-Disposition are a good idea >> but, since this is a 8bit safe system, I think we should say things >> SHOULD >> be sent with a Content-Transfer-Encoding of binary and all the examples >> should show this. This caused many interoperability headaches in page >> mode. >> > > Agree. Further more, I wouldn't mind if the spec says that the default > transfer encoding is binary in the absence of the > Content-Transfer-Encoding. > > /Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 11:58:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26676 for ; Wed, 19 Nov 2003 11:58:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVeb-0007EV-Rz for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:58:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJGw9f4027797 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 11:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVeb-0007EG-NZ for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 11:58:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26608; Wed, 19 Nov 2003 11:57:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVeZ-0003DP-00; Wed, 19 Nov 2003 11:58:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMVeZ-0003DM-00; Wed, 19 Nov 2003 11:58:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVeT-0007D2-KA; Wed, 19 Nov 2003 11:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMVdb-0007Bb-HC for simple@optimus.ietf.org; Wed, 19 Nov 2003 11:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26536 for ; Wed, 19 Nov 2003 11:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMVdW-0003BA-00 for simple@ietf.org; Wed, 19 Nov 2003 11:57:02 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMVdW-0003B7-00 for simple@ietf.org; Wed, 19 Nov 2003 11:57:02 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAJGtZnG059727; Wed, 19 Nov 2003 10:55:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBBA080.4070904@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Cullen Jennings , Simple WG Subject: Re: [Simple] MSRP Open Issues References: <3FBB9CE6.70204@ericsson.com> In-Reply-To: <3FBB9CE6.70204@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 10:55:28 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Agreed on both points. Miguel A. Garcia wrote: > Cullen Jennings wrote: > >> >> I think Content-Transfer-Encoding and Content-Disposition are a good idea >> but, since this is a 8bit safe system, I think we should say things >> SHOULD >> be sent with a Content-Transfer-Encoding of binary and all the examples >> should show this. This caused many interoperability headaches in page >> mode. >> > > Agree. Further more, I wouldn't mind if the spec says that the default > transfer encoding is binary in the absence of the > Content-Transfer-Encoding. > > /Miguel > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 12:50:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29466; Wed, 19 Nov 2003 12:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWTp-0004pA-00; Wed, 19 Nov 2003 12:51:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWTp-0004p7-00; Wed, 19 Nov 2003 12:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTk-0003Ng-SB; Wed, 19 Nov 2003 12:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTc-0003Lw-Qm for simple@optimus.ietf.org; Wed, 19 Nov 2003 12:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29421 for ; Wed, 19 Nov 2003 12:50:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWTa-0004nP-00 for simple@ietf.org; Wed, 19 Nov 2003 12:50:50 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMWTY-0004n4-00 for simple@ietf.org; Wed, 19 Nov 2003 12:50:49 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAJHmcnG064474; Wed, 19 Nov 2003 11:48:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBBACEF.8030405@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , Paul Kyzivat , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 11:48:31 -0600 Content-Transfer-Encoding: 7bit 3087 has two major ideas. The first is, application behavior can be controlled by the r-URI. This is basically an extension of the idea that the r-URI designates the resource for the request. This is controversial in some areas, but not so much as the other idea. The second idea is that the _customer_ owns the namespace, not the equipment vendor. A large customer, like a major carrier will most likely have an existing provisioning system that will build and enforce said namespace. The large carrier will expect a hardware device to be remotely provisionable by automata, and will write code to actually talk to specific devices. In a lot of cases, this is done by screen-scraping a console, but other approaches can work. (Note that Robert and I were at Worldcom when we wrote the draft that became 3087...) So, from that perspective, imagine I have some proxies from vendor A, and some VM boxes from B and C. I want my provisioning system to be able to add voice mail for a user, and except for the physical mechanism of talking to the devices, I don't to think too much about which VM vendor box is used for a particular user. So, I build build my own scheme for the various URIs. The provisioning system tells a VM box to build a mailbox for User, with the URIs something like: sip:asfie@VmB.example.com -- Top level menu sip:zzzz@VmB.example.com -- User Entry pt for busy sip:yyyy@VmB.example.com -- User entry pt for no answer sip:ssweiaz@VmB.example.com -- Entry pt for when User is calling Note that my provisioning system created those URIs, using whatever method I like. Maybe they were just random. Then the provisioning system provisions the proxy to forward to those particular URIs in the appropriate circumstances. Now, of course, some vendors have customers that are not so large to have great big complicated provisioning systems. In this case, the vendore can create their own provisioning layer that exposes some standardized naming convention to the customer, but works exactly the same way underneath the layer. The useful thing about this approach, is if I create a completely new VM related application, I can simply add it without any new standards work. For example, pehaps I want an entry point for when the caller is a known telemarketer. If we depend on standardized naming conventions, then it is harder for me to deploy any new service for which a convention does not already exist. Now, to the point of exploders: This is a little different, because we expect the UAC to feed dynamic information to the UAS, thus requiring the UAC to know how to construct the r-URI. The UAC may need to do this for many different exploders in different management domains. Therefore, it may make sense to have a URI convention for this. Cullen Jennings wrote: > Several people have mentioned my previous VM-URI draft demonstrated a > completely lack of understanding of 3087 on my part. This is true - I don't > think I fully get what is says. So help me understand in context of this > ad-hoc subscription stuff.... > > I think you are suggesting that Customer A might configure their phones and > proxies to use a URI like > > fluffy%40cisco.com+rohan%40cisco.com@example.com > > Customer B might configure them to be > > fluff_at_cisco.com_and_rohan_at_cisco.com@example.com > > Customer C might use > > fluffy%40cisco.com;rohan%40cisco.com@example.com > > Customer D might use > > exploder:to=fluffy%40cisco.com:to=rohan%40cisco.com@example.com > > And the proxies and UA are coning to be arbitrarily configurable to support > all of these in a way that the administrator understands even when they all > come from different vendors. Just look a the problems caused by configuring > the most trivial of dial plans in phones today. > > I really hope this is not what 3087 recommended, because if it does, I > suspect it will never pass the running code test. Can you imagine what the > manual for the proxy would like that explained to some network administrator > how to do this, It's just not practical. What about a phone that formed > composites sets of names differently depending on where it was going to > request the same service from. > > If you think the ad-hoc lists or exploders idea is useful, then we should > work out a convention for doing it. I don't care if it is in a body, header, > or URI. > > > > On 11/17/03 4:57 PM, "Adam Roach" wrote: > > >> >>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >>>Adam Roach wrote: >>> >>> >>>>Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>>> >>>> >>>> >>>>>[U]nless there is an agreement on how to standardize >>>>>servers (by name or whatever), there isn't really much need to >>>>>standardize *anything* about this behavior - even the name of the >>>>>parameter (list=). It perhaps just becomes some sort of best >>>>>practices or informational draft. >>>> >>>> >>>>I came to the same conclusion. I think I like that fact. >>>> >>> >>>I don't think this affects the need for standardization one way or >>>another. We can standardize that the R-URI designates the application >>>receiving the request, and leave the rest open. >> >>Isn't that precisely what RFC 3087 already says? >> >> >>>But we could also decide that a particular application (e.g. >>>subscribing to an add-hoc list) is sufficiently interesting when >>>interoperable to standardize that application. >> >>I could easily see a standards-track document that defines >>semantics for a "list" parameter on a SIP URI (i.e. it points >>to a URI that, when dereferenced, contains a list of recipients >>that the application being invoked knows how to handle). Would >>that accomplish what you want to do? >> >>/a >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 12:51:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29517 for ; Wed, 19 Nov 2003 12:51:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTs-0003PK-Le for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 12:51:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJHp8w6013097 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 12:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTs-0003PA-IT for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 12:51:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29466; Wed, 19 Nov 2003 12:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWTp-0004pA-00; Wed, 19 Nov 2003 12:51:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMWTp-0004p7-00; Wed, 19 Nov 2003 12:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTk-0003Ng-SB; Wed, 19 Nov 2003 12:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMWTc-0003Lw-Qm for simple@optimus.ietf.org; Wed, 19 Nov 2003 12:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29421 for ; Wed, 19 Nov 2003 12:50:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMWTa-0004nP-00 for simple@ietf.org; Wed, 19 Nov 2003 12:50:50 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMWTY-0004n4-00 for simple@ietf.org; Wed, 19 Nov 2003 12:50:49 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAJHmcnG064474; Wed, 19 Nov 2003 11:48:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBBACEF.8030405@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , Paul Kyzivat , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 11:48:31 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 3087 has two major ideas. The first is, application behavior can be controlled by the r-URI. This is basically an extension of the idea that the r-URI designates the resource for the request. This is controversial in some areas, but not so much as the other idea. The second idea is that the _customer_ owns the namespace, not the equipment vendor. A large customer, like a major carrier will most likely have an existing provisioning system that will build and enforce said namespace. The large carrier will expect a hardware device to be remotely provisionable by automata, and will write code to actually talk to specific devices. In a lot of cases, this is done by screen-scraping a console, but other approaches can work. (Note that Robert and I were at Worldcom when we wrote the draft that became 3087...) So, from that perspective, imagine I have some proxies from vendor A, and some VM boxes from B and C. I want my provisioning system to be able to add voice mail for a user, and except for the physical mechanism of talking to the devices, I don't to think too much about which VM vendor box is used for a particular user. So, I build build my own scheme for the various URIs. The provisioning system tells a VM box to build a mailbox for User, with the URIs something like: sip:asfie@VmB.example.com -- Top level menu sip:zzzz@VmB.example.com -- User Entry pt for busy sip:yyyy@VmB.example.com -- User entry pt for no answer sip:ssweiaz@VmB.example.com -- Entry pt for when User is calling Note that my provisioning system created those URIs, using whatever method I like. Maybe they were just random. Then the provisioning system provisions the proxy to forward to those particular URIs in the appropriate circumstances. Now, of course, some vendors have customers that are not so large to have great big complicated provisioning systems. In this case, the vendore can create their own provisioning layer that exposes some standardized naming convention to the customer, but works exactly the same way underneath the layer. The useful thing about this approach, is if I create a completely new VM related application, I can simply add it without any new standards work. For example, pehaps I want an entry point for when the caller is a known telemarketer. If we depend on standardized naming conventions, then it is harder for me to deploy any new service for which a convention does not already exist. Now, to the point of exploders: This is a little different, because we expect the UAC to feed dynamic information to the UAS, thus requiring the UAC to know how to construct the r-URI. The UAC may need to do this for many different exploders in different management domains. Therefore, it may make sense to have a URI convention for this. Cullen Jennings wrote: > Several people have mentioned my previous VM-URI draft demonstrated a > completely lack of understanding of 3087 on my part. This is true - I don't > think I fully get what is says. So help me understand in context of this > ad-hoc subscription stuff.... > > I think you are suggesting that Customer A might configure their phones and > proxies to use a URI like > > fluffy%40cisco.com+rohan%40cisco.com@example.com > > Customer B might configure them to be > > fluff_at_cisco.com_and_rohan_at_cisco.com@example.com > > Customer C might use > > fluffy%40cisco.com;rohan%40cisco.com@example.com > > Customer D might use > > exploder:to=fluffy%40cisco.com:to=rohan%40cisco.com@example.com > > And the proxies and UA are coning to be arbitrarily configurable to support > all of these in a way that the administrator understands even when they all > come from different vendors. Just look a the problems caused by configuring > the most trivial of dial plans in phones today. > > I really hope this is not what 3087 recommended, because if it does, I > suspect it will never pass the running code test. Can you imagine what the > manual for the proxy would like that explained to some network administrator > how to do this, It's just not practical. What about a phone that formed > composites sets of names differently depending on where it was going to > request the same service from. > > If you think the ad-hoc lists or exploders idea is useful, then we should > work out a convention for doing it. I don't care if it is in a body, header, > or URI. > > > > On 11/17/03 4:57 PM, "Adam Roach" wrote: > > >> >>Ben Campbell [mailto:bcampbell@dynamicsoft.com] writes: >> >>>Adam Roach wrote: >>> >>> >>>>Paul Kyzivat [mailto:pkyzivat@cisco.com] writes: >>>> >>>> >>>> >>>>>[U]nless there is an agreement on how to standardize >>>>>servers (by name or whatever), there isn't really much need to >>>>>standardize *anything* about this behavior - even the name of the >>>>>parameter (list=). It perhaps just becomes some sort of best >>>>>practices or informational draft. >>>> >>>> >>>>I came to the same conclusion. I think I like that fact. >>>> >>> >>>I don't think this affects the need for standardization one way or >>>another. We can standardize that the R-URI designates the application >>>receiving the request, and leave the rest open. >> >>Isn't that precisely what RFC 3087 already says? >> >> >>>But we could also decide that a particular application (e.g. >>>subscribing to an add-hoc list) is sufficiently interesting when >>>interoperable to standardize that application. >> >>I could easily see a standards-track document that defines >>semantics for a "list" parameter on a SIP URI (i.e. it points >>to a URI that, when dereferenced, contains a list of recipients >>that the application being invoked knows how to handle). Would >>that accomplish what you want to do? >> >>/a >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 18:54:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23960; Wed, 19 Nov 2003 18:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcA6-0006bJ-00; Wed, 19 Nov 2003 18:55:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMcA6-0006bG-00; Wed, 19 Nov 2003 18:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcA3-0007CS-8i; Wed, 19 Nov 2003 18:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMc9o-0007BY-Si for simple@optimus.ietf.org; Wed, 19 Nov 2003 18:54:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23951 for ; Wed, 19 Nov 2003 18:54:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc9l-0006aw-00 for simple@ietf.org; Wed, 19 Nov 2003 18:54:45 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AMc9l-0006ag-00 for simple@ietf.org; Wed, 19 Nov 2003 18:54:45 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAJNsF9d025122; Wed, 19 Nov 2003 17:54:15 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 17:54:14 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86638@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Orit Levin'" , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 17:54:13 -0600 Orit Levin [mailto:oritl@microsoft.com] writes: > Are we planning to automatically distribute the dynamic lists > across the network using XCAP? To my understanding, that was the original plan. That said, companies working in the wireless space have been promoting a requirement that devices that use short-lived lists must be able to send the list and the operation that uses the list in a single transaction. I understand this requirement, and think we need some specification to address it. I plan to submit an internet draft that expands on the ideas I have championed in this thread as soon as I have time. Your recent draft makes it clear that using XCAP for these temporary lists doesn't meet your requirements either -- but it doesn't clarify what requirements you have on short- lived lists. What I would like to know from you is: is this requirement (a single transaction to specify and use a list) the same as what you need, or do you have additional and/or different requirements? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 18:55:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24014 for ; Wed, 19 Nov 2003 18:55:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcAA-0007DL-Bq for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 18:55:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJNtAfV027725 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 18:55:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcAA-0007D5-7Q for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 18:55:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23960; Wed, 19 Nov 2003 18:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcA6-0006bJ-00; Wed, 19 Nov 2003 18:55:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMcA6-0006bG-00; Wed, 19 Nov 2003 18:55:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcA3-0007CS-8i; Wed, 19 Nov 2003 18:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMc9o-0007BY-Si for simple@optimus.ietf.org; Wed, 19 Nov 2003 18:54:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23951 for ; Wed, 19 Nov 2003 18:54:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMc9l-0006aw-00 for simple@ietf.org; Wed, 19 Nov 2003 18:54:45 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AMc9l-0006ag-00 for simple@ietf.org; Wed, 19 Nov 2003 18:54:45 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAJNsF9d025122; Wed, 19 Nov 2003 17:54:15 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Nov 2003 17:54:14 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86638@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Orit Levin'" , simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 17:54:13 -0600 Orit Levin [mailto:oritl@microsoft.com] writes: > Are we planning to automatically distribute the dynamic lists > across the network using XCAP? To my understanding, that was the original plan. That said, companies working in the wireless space have been promoting a requirement that devices that use short-lived lists must be able to send the list and the operation that uses the list in a single transaction. I understand this requirement, and think we need some specification to address it. I plan to submit an internet draft that expands on the ideas I have championed in this thread as soon as I have time. Your recent draft makes it clear that using XCAP for these temporary lists doesn't meet your requirements either -- but it doesn't clarify what requirements you have on short- lived lists. What I would like to know from you is: is this requirement (a single transaction to specify and use a list) the same as what you need, or do you have additional and/or different requirements? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 19:36:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25743; Wed, 19 Nov 2003 19:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcok-0007Yg-00; Wed, 19 Nov 2003 19:37:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMcok-0007Yd-00; Wed, 19 Nov 2003 19:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcog-0000ED-6o; Wed, 19 Nov 2003 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcoL-0000DG-Hi for simple@optimus.ietf.org; Wed, 19 Nov 2003 19:36:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25720 for ; Wed, 19 Nov 2003 19:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcoJ-0007Y6-00 for simple@ietf.org; Wed, 19 Nov 2003 19:36:39 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMcoJ-0007XL-00 for simple@ietf.org; Wed, 19 Nov 2003 19:36:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAK0ZxnG098685; Wed, 19 Nov 2003 18:36:04 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBC0C66.2020906@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , Paul Kyzivat , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 18:35:50 -0600 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/19/03 9:48 AM, "Ben Campbell" wrote: > > >>3087 has two major ideas. The first is, application behavior can be >>controlled by the r-URI. This is basically an extension of the idea that >>the r-URI designates the resource for the request. This is controversial >>in some areas, but not so much as the other idea. >> >>The second idea is that the _customer_ owns the namespace, not the >>equipment vendor. > > > Ok, that makes some sense but clearly interoperable conventions in this > namespace are very useful. For example if the r-URI to most PSTN gateways > was something like > > +1-555-555-01000@gw.example.com;user=phone the result would be pretty > predictable. I do not disagree. Conventions definitely make interop easier. But they also tend to limit what you can talk about. I do not have a problem coming up with conventions for well-known applications that everyone uses. Your example above probably qualifies. Exploders may qualify. VM is sort of in a gray area, as I think there is room for all sorts of interesting, non-conventional approaches. One _really_ big problem facing carriers these days is difficulty in deploying new services. I think this will be the death of some of the "conventional" telecom carriers in the long run. 3087 is all about trying to make it easier to create new (hopefully innovative) services. This was something that my employer (at the time of the original writing) was really worrying about. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 19:37:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26157 for ; Wed, 19 Nov 2003 19:37:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcoo-0000LL-8Y for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 19:37:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK0bAO8001313 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 19:37:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcon-0000L2-TS for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 19:37:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25743; Wed, 19 Nov 2003 19:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcok-0007Yg-00; Wed, 19 Nov 2003 19:37:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMcok-0007Yd-00; Wed, 19 Nov 2003 19:37:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcog-0000ED-6o; Wed, 19 Nov 2003 19:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcoL-0000DG-Hi for simple@optimus.ietf.org; Wed, 19 Nov 2003 19:36:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25720 for ; Wed, 19 Nov 2003 19:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcoJ-0007Y6-00 for simple@ietf.org; Wed, 19 Nov 2003 19:36:39 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMcoJ-0007XL-00 for simple@ietf.org; Wed, 19 Nov 2003 19:36:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAK0ZxnG098685; Wed, 19 Nov 2003 18:36:04 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBC0C66.2020906@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , Paul Kyzivat , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 18:35:50 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > On 11/19/03 9:48 AM, "Ben Campbell" wrote: > > >>3087 has two major ideas. The first is, application behavior can be >>controlled by the r-URI. This is basically an extension of the idea that >>the r-URI designates the resource for the request. This is controversial >>in some areas, but not so much as the other idea. >> >>The second idea is that the _customer_ owns the namespace, not the >>equipment vendor. > > > Ok, that makes some sense but clearly interoperable conventions in this > namespace are very useful. For example if the r-URI to most PSTN gateways > was something like > > +1-555-555-01000@gw.example.com;user=phone the result would be pretty > predictable. I do not disagree. Conventions definitely make interop easier. But they also tend to limit what you can talk about. I do not have a problem coming up with conventions for well-known applications that everyone uses. Your example above probably qualifies. Exploders may qualify. VM is sort of in a gray area, as I think there is room for all sorts of interesting, non-conventional approaches. One _really_ big problem facing carriers these days is difficulty in deploying new services. I think this will be the death of some of the "conventional" telecom carriers in the long run. 3087 is all about trying to make it easier to create new (hopefully innovative) services. This was something that my employer (at the time of the original writing) was really worrying about. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 19:38:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26207; Wed, 19 Nov 2003 19:38:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMcpu-0007dt-00; Wed, 19 Nov 2003 19:38:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMcpt-0007dh-00; Wed, 19 Nov 2003 19:38:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcpe-0000es-6k; Wed, 19 Nov 2003 19:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMcop-0000Lt-S0 for simple@optimus.ietf.org; Wed, 19 Nov 2003 19:37:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25783 for ; Wed, 19 Nov 2003 19:36:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMckm-0007Hs-00 for simple@ietf.org; Wed, 19 Nov 2003 19:33:00 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMcYR-0006zX-00 for simple@ietf.org; Wed, 19 Nov 2003 19:20:15 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Nov 2003 16:19:59 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAK0Jgjq022334; Wed, 19 Nov 2003 16:19:43 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKC46045; Wed, 19 Nov 2003 16:19:41 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) From: Cullen Jennings To: Ben Campbell CC: Adam Roach , Paul Kyzivat , , Dean Willis , Jonathan Rosenberg , Message-ID: In-Reply-To: <3FBBACEF.8030405@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 16:19:41 -0800 Content-Transfer-Encoding: 7bit On 11/19/03 9:48 AM, "Ben Campbell" wrote: > 3087 has two major ideas. The first is, application behavior can be > controlled by the r-URI. This is basically an extension of the idea that > the r-URI designates the resource for the request. This is controversial > in some areas, but not so much as the other idea. > > The second idea is that the _customer_ owns the namespace, not the > equipment vendor. Ok, that makes some sense but clearly interoperable conventions in this namespace are very useful. For example if the r-URI to most PSTN gateways was something like +1-555-555-01000@gw.example.com;user=phone the result would be pretty predictable. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 19 20:34:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28603; Wed, 19 Nov 2003 20:34:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMdis-0000re-00; Wed, 19 Nov 2003 20:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMdis-0000rb-00; Wed, 19 Nov 2003 20:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMdio-0003tB-Kc; Wed, 19 Nov 2003 20:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMdiP-0003pj-HR for simple@optimus.ietf.org; Wed, 19 Nov 2003 20:34:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28556 for ; Wed, 19 Nov 2003 20:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMdiN-0000qd-00 for simple@ietf.org; Wed, 19 Nov 2003 20:34:35 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AMdiM-0000q6-00 for simple@ietf.org; Wed, 19 Nov 2003 20:34:34 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Nov 2003 17:34:04 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Nov 2003 17:34:04 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 17:34:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOu+IcGUyjVrR1CTweSdoQpjxNZxwACEoRg From: "Orit Levin" To: "Adam Roach" , X-OriginalArrivalTime: 20 Nov 2003 01:34:04.0240 (UTC) FILETIME=[61D32D00:01C3AF06] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 17:34:07 -0800 Content-Transfer-Encoding: quoted-printable First of all, I am glad that I am not alone :-) As a direct outcome of the discussion around the ad-hoc list topic in the SIMPLE session, I identified to myself a clear AI to come up with a requirements draft for how we distribute the dynamic information, vital for building scalable and interoperable SIMPLE infrastructures. The user's "subscribe list" - is one simple example. - "Single transaction mechanism" is an important requirement to me as well. - Ability to send deltas of a list is also crucial (apropos the discussed exploders' syntax). I also see requirements for exchanging highly dynamic information between/among "Presence Servers" in optimized (e.g. compact) way. When doing all this, I will love to reuse as many basic XML presence schemas as possible. Creation of the requirements draft is a very high priority on my list. I suggest that we join our efforts and create a taskforce in order to come up with suggestions/conclusions/directions... faster than usually. I believe that we are in shortage of time here in order for the standards to be adopted by the industry. Orit.=20 -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com]=20 Sent: Wednesday, November 19, 2003 3:54 PM To: Orit Levin; simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions Orit Levin [mailto:oritl@microsoft.com] writes: > Are we planning to automatically distribute the dynamic lists=20 > across the network using XCAP? To my understanding, that was the original plan. That said, companies working in the wireless space have been promoting a requirement that devices that use short-lived lists must be able to send the list and the operation that uses the list in a single transaction. I understand this requirement, and think we need some specification to address it. I plan to submit an internet draft that expands on the ideas I have championed in this thread as soon as I have time. Your recent draft makes it clear that using XCAP for these temporary lists doesn't meet your requirements either -- but it doesn't clarify what requirements you have on short- lived lists. What I would like to know from you is: is this requirement (a single transaction to specify and use a list) the same as what you need, or do you have additional and/or different requirements? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 19 20:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28676 for ; Wed, 19 Nov 2003 20:35:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMdiv-0003ui-IV for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 20:35:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK1Z9Z4015038 for simple-archive@odin.ietf.org; Wed, 19 Nov 2003 20:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMdiv-0003uT-BB for simple-web-archive@optimus.ietf.org; Wed, 19 Nov 2003 20:35:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28603; Wed, 19 Nov 2003 20:34:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMdis-0000re-00; Wed, 19 Nov 2003 20:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMdis-0000rb-00; Wed, 19 Nov 2003 20:35:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMdio-0003tB-Kc; Wed, 19 Nov 2003 20:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMdiP-0003pj-HR for simple@optimus.ietf.org; Wed, 19 Nov 2003 20:34:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28556 for ; Wed, 19 Nov 2003 20:34:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMdiN-0000qd-00 for simple@ietf.org; Wed, 19 Nov 2003 20:34:35 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AMdiM-0000q6-00 for simple@ietf.org; Wed, 19 Nov 2003 20:34:34 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 19 Nov 2003 17:34:04 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Nov 2003 17:34:04 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 17:34:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOu+IcGUyjVrR1CTweSdoQpjxNZxwACEoRg From: "Orit Levin" To: "Adam Roach" , X-OriginalArrivalTime: 20 Nov 2003 01:34:04.0240 (UTC) FILETIME=[61D32D00:01C3AF06] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 17:34:07 -0800 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable First of all, I am glad that I am not alone :-) As a direct outcome of the discussion around the ad-hoc list topic in the SIMPLE session, I identified to myself a clear AI to come up with a requirements draft for how we distribute the dynamic information, vital for building scalable and interoperable SIMPLE infrastructures. The user's "subscribe list" - is one simple example. - "Single transaction mechanism" is an important requirement to me as well. - Ability to send deltas of a list is also crucial (apropos the discussed exploders' syntax). I also see requirements for exchanging highly dynamic information between/among "Presence Servers" in optimized (e.g. compact) way. When doing all this, I will love to reuse as many basic XML presence schemas as possible. Creation of the requirements draft is a very high priority on my list. I suggest that we join our efforts and create a taskforce in order to come up with suggestions/conclusions/directions... faster than usually. I believe that we are in shortage of time here in order for the standards to be adopted by the industry. Orit.=20 -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com]=20 Sent: Wednesday, November 19, 2003 3:54 PM To: Orit Levin; simple@ietf.org Subject: RE: [Simple] ad-hoc list subscriptions Orit Levin [mailto:oritl@microsoft.com] writes: > Are we planning to automatically distribute the dynamic lists=20 > across the network using XCAP? To my understanding, that was the original plan. That said, companies working in the wireless space have been promoting a requirement that devices that use short-lived lists must be able to send the list and the operation that uses the list in a single transaction. I understand this requirement, and think we need some specification to address it. I plan to submit an internet draft that expands on the ideas I have championed in this thread as soon as I have time. Your recent draft makes it clear that using XCAP for these temporary lists doesn't meet your requirements either -- but it doesn't clarify what requirements you have on short- lived lists. What I would like to know from you is: is this requirement (a single transaction to specify and use a list) the same as what you need, or do you have additional and/or different requirements? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 00:05:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03978; Thu, 20 Nov 2003 00:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMh0z-0003VE-00; Thu, 20 Nov 2003 00:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMh0z-0003VB-00; Thu, 20 Nov 2003 00:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMh0z-0004LB-8B; Thu, 20 Nov 2003 00:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMh01-0004Jp-8l for simple@optimus.ietf.org; Thu, 20 Nov 2003 00:05:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03955 for ; Thu, 20 Nov 2003 00:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMgzy-0003UX-00 for simple@ietf.org; Thu, 20 Nov 2003 00:04:58 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMgzy-0003U6-00 for simple@ietf.org; Thu, 20 Nov 2003 00:04:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAK54Td22731 for ; Wed, 19 Nov 2003 23:04:29 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1069304667.973.75.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Draft minutes from the SIMPLE IETF58 meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 23:04:28 -0600 Content-Transfer-Encoding: 7bit Draft minutes for last week's meeting are available at http://www.nostrum.com/~rjsparks/minutes-simple-ietf58.txt Please provide corrections or comments to the list or directly to me no later than Wednesday November 26. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 00:06:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04000 for ; Thu, 20 Nov 2003 00:06:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMh12-0004ME-J2 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 00:06:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK564Sk016744 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 00:06:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMh12-0004Lz-Ea for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 00:06:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03978; Thu, 20 Nov 2003 00:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMh0z-0003VE-00; Thu, 20 Nov 2003 00:06:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMh0z-0003VB-00; Thu, 20 Nov 2003 00:06:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMh0z-0004LB-8B; Thu, 20 Nov 2003 00:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMh01-0004Jp-8l for simple@optimus.ietf.org; Thu, 20 Nov 2003 00:05:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03955 for ; Thu, 20 Nov 2003 00:04:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMgzy-0003UX-00 for simple@ietf.org; Thu, 20 Nov 2003 00:04:58 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMgzy-0003U6-00 for simple@ietf.org; Thu, 20 Nov 2003 00:04:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAK54Td22731 for ; Wed, 19 Nov 2003 23:04:29 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1069304667.973.75.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Draft minutes from the SIMPLE IETF58 meeting Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 19 Nov 2003 23:04:28 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Draft minutes for last week's meeting are available at http://www.nostrum.com/~rjsparks/minutes-simple-ietf58.txt Please provide corrections or comments to the list or directly to me no later than Wednesday November 26. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 02:29:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20557; Thu, 20 Nov 2003 02:29:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjG8-0005Ev-00; Thu, 20 Nov 2003 02:29:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjG8-0005Es-00; Thu, 20 Nov 2003 02:29:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjFO-0003YH-9p; Thu, 20 Nov 2003 02:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjF7-0003Xn-0B for simple@optimus.ietf.org; Thu, 20 Nov 2003 02:28:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20549 for ; Thu, 20 Nov 2003 02:28:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjF3-0005Ea-00 for simple@ietf.org; Thu, 20 Nov 2003 02:28:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMjF2-0005EX-00 for simple@ietf.org; Thu, 20 Nov 2003 02:28:41 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK7Se606435 for ; Thu, 20 Nov 2003 09:28:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 09:28:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 09:28:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Objects to NATs kill TCP connection Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973F4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Objects to NATs kill TCP connection Thread-Index: AcOuqMCMS1Kh+5eOSqWD2b2v4JZo3gAjsHLw To: Cc: , , , X-OriginalArrivalTime: 20 Nov 2003 07:28:39.0042 (UTC) FILETIME=[EA985620:01C3AF37] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 09:28:38 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 19.November.2003 16:23 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: pkyzivat@cisco.com; jdrosen@dynamicsoft.com; fluffy@cisco.com; > simple@ietf.org > Subject: Re: [Simple] Objects to NATs kill TCP connection >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Paul Kyzivat > >>Sent: 18.November.2003 21:13 > >>To: Ben Campbell > >>Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org > >>Subject: Re: [Simple] Objects to NATs kill TCP connection > >> > >> > >> > >> > >>Ben Campbell wrote: > >> > >>>Can we reasonably assume that all connection failures are=20 > >> > >>due to NATs?=20 > >> > >>>What happens if endpoints do this when the failure is caused by=20 > >>>something else? > >> > >>Good point. That could be ugly - I don't see any easy way to=20 > >>know when=20 > >>the connection fails because of NAT. Lacking that it seems=20 > >>infeasible to=20 > >>test for the NAT timeout interval. > >> > >>Are there any standard practices in this regard? In other words, is=20 > >>there a keepalive time we could use that would be sufficient=20 > >>most of the=20 > >>time and still not be too impractical to keep up? > >=20 > >=20 > > To be safe, you need a keepalive message every 30 seconds.=20 > You can always send empty TCP packets. > >=20 > > Shouldn't this anyway be a relay problem? maybe a BIND is=20 > sent to the relay every x seconds. >=20 > It can occur without any relays. For example, what if one=20 > (the active)=20 > endpoint is natted and the other is not? This scenario works=20 > with no relays. We had relays in the protocol to solve such problems of NAT and firewall = traversal. Lets not try to solve the problems introduced by NATS and = firewalls without relays. MS(R)P does not support NAT and firewall traversal without relays. Am I = missing something? /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 02:30:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20590 for ; Thu, 20 Nov 2003 02:30:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjGK-0003c3-Cu for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 02:30:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7TxJB013877 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 02:29:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjGG-0003bI-Qy for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 02:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20557; Thu, 20 Nov 2003 02:29:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjG8-0005Ev-00; Thu, 20 Nov 2003 02:29:48 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjG8-0005Es-00; Thu, 20 Nov 2003 02:29:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjFO-0003YH-9p; Thu, 20 Nov 2003 02:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjF7-0003Xn-0B for simple@optimus.ietf.org; Thu, 20 Nov 2003 02:28:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20549 for ; Thu, 20 Nov 2003 02:28:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjF3-0005Ea-00 for simple@ietf.org; Thu, 20 Nov 2003 02:28:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMjF2-0005EX-00 for simple@ietf.org; Thu, 20 Nov 2003 02:28:41 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK7Se606435 for ; Thu, 20 Nov 2003 09:28:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 09:28:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 09:28:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Objects to NATs kill TCP connection Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973F4@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Objects to NATs kill TCP connection Thread-Index: AcOuqMCMS1Kh+5eOSqWD2b2v4JZo3gAjsHLw To: Cc: , , , X-OriginalArrivalTime: 20 Nov 2003 07:28:39.0042 (UTC) FILETIME=[EA985620:01C3AF37] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 09:28:38 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 19.November.2003 16:23 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: pkyzivat@cisco.com; jdrosen@dynamicsoft.com; fluffy@cisco.com; > simple@ietf.org > Subject: Re: [Simple] Objects to NATs kill TCP connection >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Paul Kyzivat > >>Sent: 18.November.2003 21:13 > >>To: Ben Campbell > >>Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org > >>Subject: Re: [Simple] Objects to NATs kill TCP connection > >> > >> > >> > >> > >>Ben Campbell wrote: > >> > >>>Can we reasonably assume that all connection failures are=20 > >> > >>due to NATs?=20 > >> > >>>What happens if endpoints do this when the failure is caused by=20 > >>>something else? > >> > >>Good point. That could be ugly - I don't see any easy way to=20 > >>know when=20 > >>the connection fails because of NAT. Lacking that it seems=20 > >>infeasible to=20 > >>test for the NAT timeout interval. > >> > >>Are there any standard practices in this regard? In other words, is=20 > >>there a keepalive time we could use that would be sufficient=20 > >>most of the=20 > >>time and still not be too impractical to keep up? > >=20 > >=20 > > To be safe, you need a keepalive message every 30 seconds.=20 > You can always send empty TCP packets. > >=20 > > Shouldn't this anyway be a relay problem? maybe a BIND is=20 > sent to the relay every x seconds. >=20 > It can occur without any relays. For example, what if one=20 > (the active)=20 > endpoint is natted and the other is not? This scenario works=20 > with no relays. We had relays in the protocol to solve such problems of NAT and firewall = traversal. Lets not try to solve the problems introduced by NATS and = firewalls without relays. MS(R)P does not support NAT and firewall traversal without relays. Am I = missing something? /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 02:41:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21118; Thu, 20 Nov 2003 02:41:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjRg-0005ZL-00; Thu, 20 Nov 2003 02:41:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjRg-0005YZ-00; Thu, 20 Nov 2003 02:41:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjQ1-00059x-Pi; Thu, 20 Nov 2003 02:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjPj-00059C-OZ for simple@optimus.ietf.org; Thu, 20 Nov 2003 02:39:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21047 for ; Thu, 20 Nov 2003 02:39:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjPg-0005YQ-00 for simple@ietf.org; Thu, 20 Nov 2003 02:39:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMjPg-0005YN-00 for simple@ietf.org; Thu, 20 Nov 2003 02:39:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK7dd621471 for ; Thu, 20 Nov 2003 09:39:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 09:39:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 09:39:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B0FA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOu+IcGUyjVrR1CTweSdoQpjxNZxwACEoRgAA4JleA= To: , , Cc: X-OriginalArrivalTime: 20 Nov 2003 07:39:39.0673 (UTC) FILETIME=[745CA090:01C3AF39] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 09:39:39 +0200 Content-Transfer-Encoding: quoted-printable As I said on the mike in the SIMPLE meeting, this issue is not just = limited to SUBSCRIBE, but the problem also includes MESSAGE, INVITE, = etc. There are already requirements documented in = http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00.= txt Should we discuss those in sipping? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 20.November.2003 03:34 > To: Adam Roach; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 >=20 > First of all, I am glad that I am not alone :-) >=20 > As a direct outcome of the discussion around the ad-hoc list topic in > the SIMPLE session, I identified to myself a clear AI to come=20 > up with a > requirements draft for how we distribute the dynamic=20 > information, vital > for building scalable and interoperable SIMPLE infrastructures. >=20 > The user's "subscribe list" - is one simple example. > - "Single transaction mechanism" is an important requirement to me as > well. - Ability to send deltas of a list is also crucial (apropos the > discussed exploders' syntax). >=20 > I also see requirements for exchanging highly dynamic information > between/among "Presence Servers" in optimized (e.g. compact) way. >=20 > When doing all this, I will love to reuse as many basic XML presence > schemas as possible. >=20 > Creation of the requirements draft is a very high priority on=20 > my list. I > suggest that we join our efforts and create a taskforce in=20 > order to come > up with suggestions/conclusions/directions... faster than usually. >=20 > I believe that we are in shortage of time here in order for the > standards to be adopted by the industry. >=20 > Orit.=20 >=20 >=20 >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com]=20 > Sent: Wednesday, November 19, 2003 3:54 PM > To: Orit Levin; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 > Orit Levin [mailto:oritl@microsoft.com] writes: >=20 > > Are we planning to automatically distribute the dynamic lists=20 > > across the network using XCAP? >=20 > To my understanding, that was the original plan. >=20 > That said, companies working in the wireless space have > been promoting a requirement that devices that use > short-lived lists must be able to send the list and the > operation that uses the list in a single transaction. >=20 > I understand this requirement, and think we need some > specification to address it. I plan to submit an internet > draft that expands on the ideas I have championed in this > thread as soon as I have time. >=20 > Your recent draft makes it clear that using XCAP for these > temporary lists doesn't meet your requirements either -- > but it doesn't clarify what requirements you have on short- > lived lists. What I would like to know from you is: is this > requirement (a single transaction to specify and use a list) > the same as what you need, or do you have additional and/or > different requirements? >=20 > /a >=20 >=20 >=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 exim@www1.ietf.org Thu Nov 20 02:42:52 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21195 for ; Thu, 20 Nov 2003 02:42:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjSV-0005Iu-HB for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 02:42:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAK7gZOv020385 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 02:42:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjST-0005IV-TJ for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 02:42:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21118; Thu, 20 Nov 2003 02:41:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjRg-0005ZL-00; Thu, 20 Nov 2003 02:41:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMjRg-0005YZ-00; Thu, 20 Nov 2003 02:41:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjQ1-00059x-Pi; Thu, 20 Nov 2003 02:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMjPj-00059C-OZ for simple@optimus.ietf.org; Thu, 20 Nov 2003 02:39:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21047 for ; Thu, 20 Nov 2003 02:39:30 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMjPg-0005YQ-00 for simple@ietf.org; Thu, 20 Nov 2003 02:39:40 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AMjPg-0005YN-00 for simple@ietf.org; Thu, 20 Nov 2003 02:39:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAK7dd621471 for ; Thu, 20 Nov 2003 09:39:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 20 Nov 2003 09:39:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 20 Nov 2003 09:39:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ad-hoc list subscriptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B0FA@esebe019.ntc.nokia.com> Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOu+IcGUyjVrR1CTweSdoQpjxNZxwACEoRgAA4JleA= To: , , Cc: X-OriginalArrivalTime: 20 Nov 2003 07:39:39.0673 (UTC) FILETIME=[745CA090:01C3AF39] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 09:39:39 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable As I said on the mike in the SIMPLE meeting, this issue is not just = limited to SUBSCRIBE, but the problem also includes MESSAGE, INVITE, = etc. There are already requirements documented in = http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00.= txt Should we discuss those in sipping? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 20.November.2003 03:34 > To: Adam Roach; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 >=20 > First of all, I am glad that I am not alone :-) >=20 > As a direct outcome of the discussion around the ad-hoc list topic in > the SIMPLE session, I identified to myself a clear AI to come=20 > up with a > requirements draft for how we distribute the dynamic=20 > information, vital > for building scalable and interoperable SIMPLE infrastructures. >=20 > The user's "subscribe list" - is one simple example. > - "Single transaction mechanism" is an important requirement to me as > well. - Ability to send deltas of a list is also crucial (apropos the > discussed exploders' syntax). >=20 > I also see requirements for exchanging highly dynamic information > between/among "Presence Servers" in optimized (e.g. compact) way. >=20 > When doing all this, I will love to reuse as many basic XML presence > schemas as possible. >=20 > Creation of the requirements draft is a very high priority on=20 > my list. I > suggest that we join our efforts and create a taskforce in=20 > order to come > up with suggestions/conclusions/directions... faster than usually. >=20 > I believe that we are in shortage of time here in order for the > standards to be adopted by the industry. >=20 > Orit.=20 >=20 >=20 >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com]=20 > Sent: Wednesday, November 19, 2003 3:54 PM > To: Orit Levin; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 > Orit Levin [mailto:oritl@microsoft.com] writes: >=20 > > Are we planning to automatically distribute the dynamic lists=20 > > across the network using XCAP? >=20 > To my understanding, that was the original plan. >=20 > That said, companies working in the wireless space have > been promoting a requirement that devices that use > short-lived lists must be able to send the list and the > operation that uses the list in a single transaction. >=20 > I understand this requirement, and think we need some > specification to address it. I plan to submit an internet > draft that expands on the ideas I have championed in this > thread as soon as I have time. >=20 > Your recent draft makes it clear that using XCAP for these > temporary lists doesn't meet your requirements either -- > but it doesn't clarify what requirements you have on short- > lived lists. What I would like to know from you is: is this > requirement (a single transaction to specify and use a list) > the same as what you need, or do you have additional and/or > different requirements? >=20 > /a >=20 >=20 >=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-admin@ietf.org Thu Nov 20 09:11:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04950; Thu, 20 Nov 2003 09:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpXP-0003Sn-00; Thu, 20 Nov 2003 09:12:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpXP-0003Sk-00; Thu, 20 Nov 2003 09:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpXN-00045o-3x; Thu, 20 Nov 2003 09:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpWz-00045D-DY for simple@optimus.ietf.org; Thu, 20 Nov 2003 09:11:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04910 for ; Thu, 20 Nov 2003 09:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpWx-0003Rs-00 for simple@ietf.org; Thu, 20 Nov 2003 09:11:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AMpWx-0003RP-00 for simple@ietf.org; Thu, 20 Nov 2003 09:11:35 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEB1jq008349; Thu, 20 Nov 2003 06:11:01 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED17377; Thu, 20 Nov 2003 09:10:56 -0500 (EST) Message-ID: <3FBCCB70.6060909@cisco.com> 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: Ben Campbell CC: Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 09:10:56 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > VM is sort of in a gray area, as I think there is > room for all sorts of interesting, non-conventional approaches. One > _really_ big problem facing carriers these days is difficulty in > deploying new services. I think this will be the death of some of the > "conventional" telecom carriers in the long run. 3087 is all about > trying to make it easier to create new (hopefully innovative) services. > This was something that my employer (at the time of the original > writing) was really worrying about. This makes a lot of sense, and I like the approach. But I can see how a supplier of VM systems would want to hedge its bets. This approach depends on the user having a configurable proxy that can select among all the VM alternatives. Much of the intelligence has been moved from the VM to the proxy. That is great if the VM provider is also the proxy provider. It is also probably ok if all the possible proxy providers that the VM is likely to find itself deployed with provide that functionality. But today those aren't necessarily good assumptions. To hedge the bets, the VM provider will probably want to have an alternative way to discriminate the different services on its own. So the tricky part is getting all the pieces to a stage where they can smoothly interoperate with one another. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 09:12:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04993 for ; Thu, 20 Nov 2003 09:12:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpXS-00046x-3N for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 09:12:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEC6EB015797 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 09:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpXR-00046i-WD for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04950; Thu, 20 Nov 2003 09:11:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpXP-0003Sn-00; Thu, 20 Nov 2003 09:12:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpXP-0003Sk-00; Thu, 20 Nov 2003 09:12:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpXN-00045o-3x; Thu, 20 Nov 2003 09:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpWz-00045D-DY for simple@optimus.ietf.org; Thu, 20 Nov 2003 09:11:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04910 for ; Thu, 20 Nov 2003 09:11:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpWx-0003Rs-00 for simple@ietf.org; Thu, 20 Nov 2003 09:11:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AMpWx-0003RP-00 for simple@ietf.org; Thu, 20 Nov 2003 09:11:35 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAKEB1jq008349; Thu, 20 Nov 2003 06:11:01 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AED17377; Thu, 20 Nov 2003 09:10:56 -0500 (EST) Message-ID: <3FBCCB70.6060909@cisco.com> 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: Ben Campbell CC: Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 09:10:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > VM is sort of in a gray area, as I think there is > room for all sorts of interesting, non-conventional approaches. One > _really_ big problem facing carriers these days is difficulty in > deploying new services. I think this will be the death of some of the > "conventional" telecom carriers in the long run. 3087 is all about > trying to make it easier to create new (hopefully innovative) services. > This was something that my employer (at the time of the original > writing) was really worrying about. This makes a lot of sense, and I like the approach. But I can see how a supplier of VM systems would want to hedge its bets. This approach depends on the user having a configurable proxy that can select among all the VM alternatives. Much of the intelligence has been moved from the VM to the proxy. That is great if the VM provider is also the proxy provider. It is also probably ok if all the possible proxy providers that the VM is likely to find itself deployed with provide that functionality. But today those aren't necessarily good assumptions. To hedge the bets, the VM provider will probably want to have an alternative way to discriminate the different services on its own. So the tricky part is getting all the pieces to a stage where they can smoothly interoperate with one another. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 09:17:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05204; Thu, 20 Nov 2003 09:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpdC-0003Z9-00; Thu, 20 Nov 2003 09:18:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpdC-0003Z6-00; Thu, 20 Nov 2003 09:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpdB-0004Yr-NK; Thu, 20 Nov 2003 09:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpcY-0004ST-FY for simple@optimus.ietf.org; Thu, 20 Nov 2003 09:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05174 for ; Thu, 20 Nov 2003 09:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpcW-0003YH-00 for simple@ietf.org; Thu, 20 Nov 2003 09:17:20 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMpcW-0003Y4-00 for simple@ietf.org; Thu, 20 Nov 2003 09:17:20 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAKEGunG061608; Thu, 20 Nov 2003 08:17:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBCCCD1.1000101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, jdrosen@dynamicsoft.com, fluffy@cisco.com, simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <2038BCC78B1AD641891A0D1AE133DBB7017973F4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973F4@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 08:16:49 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 19.November.2003 16:23 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: pkyzivat@cisco.com; jdrosen@dynamicsoft.com; fluffy@cisco.com; >>simple@ietf.org >>Subject: Re: [Simple] Objects to NATs kill TCP connection >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Paul Kyzivat >>>>Sent: 18.November.2003 21:13 >>>>To: Ben Campbell >>>>Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org >>>>Subject: Re: [Simple] Objects to NATs kill TCP connection >>>> >>>> >>>> >>>> >>>>Ben Campbell wrote: >>>> >>>> >>>>>Can we reasonably assume that all connection failures are >>>> >>>>due to NATs? >>>> >>>> >>>>>What happens if endpoints do this when the failure is caused by >>>>>something else? >>>> >>>>Good point. That could be ugly - I don't see any easy way to >>>>know when >>>>the connection fails because of NAT. Lacking that it seems >>>>infeasible to >>>>test for the NAT timeout interval. >>>> >>>>Are there any standard practices in this regard? In other words, is >>>>there a keepalive time we could use that would be sufficient >>>>most of the >>>>time and still not be too impractical to keep up? >>> >>> >>>To be safe, you need a keepalive message every 30 seconds. >> >>You can always send empty TCP packets. >> >>>Shouldn't this anyway be a relay problem? maybe a BIND is >> >>sent to the relay every x seconds. >> >>It can occur without any relays. For example, what if one >>(the active) >>endpoint is natted and the other is not? This scenario works >>with no relays. > > > We had relays in the protocol to solve such problems of NAT and firewall traversal. Lets not try to solve the problems introduced by NATS and firewalls without relays. > > MS(R)P does not support NAT and firewall traversal without relays. Am I missing something? Relays were primarily needed for when both endpoints were behind NATs. If only one is behind a NAT, you can work without a relay. Relays also helped with firewall policy that only allows connections to and/or from a particuclar address. But this is not always the case. If everyone things we can ignore NAT entirely in the base spec, then I will be happy to do so. There are some gray areas in the current draft that may or may not need to stay when relays are removed. I will follow up shortly with a list for discussion purposes. > > /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 09:18:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05299 for ; Thu, 20 Nov 2003 09:18:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpdE-0004Zp-Rz for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 09:18:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKEI4gO017587 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 09:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpdE-0004Za-NE for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 09:18:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05204; Thu, 20 Nov 2003 09:17:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpdC-0003Z9-00; Thu, 20 Nov 2003 09:18:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMpdC-0003Z6-00; Thu, 20 Nov 2003 09:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpdB-0004Yr-NK; Thu, 20 Nov 2003 09:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMpcY-0004ST-FY for simple@optimus.ietf.org; Thu, 20 Nov 2003 09:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05174 for ; Thu, 20 Nov 2003 09:17:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMpcW-0003YH-00 for simple@ietf.org; Thu, 20 Nov 2003 09:17:20 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMpcW-0003Y4-00 for simple@ietf.org; Thu, 20 Nov 2003 09:17:20 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAKEGunG061608; Thu, 20 Nov 2003 08:17:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBCCCD1.1000101@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, jdrosen@dynamicsoft.com, fluffy@cisco.com, simple@ietf.org Subject: Re: [Simple] Objects to NATs kill TCP connection References: <2038BCC78B1AD641891A0D1AE133DBB7017973F4@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973F4@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 08:16:49 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 19.November.2003 16:23 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: pkyzivat@cisco.com; jdrosen@dynamicsoft.com; fluffy@cisco.com; >>simple@ietf.org >>Subject: Re: [Simple] Objects to NATs kill TCP connection >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Paul Kyzivat >>>>Sent: 18.November.2003 21:13 >>>>To: Ben Campbell >>>>Cc: Jonathan Rosenberg; Cullen Jennings; simple@ietf.org >>>>Subject: Re: [Simple] Objects to NATs kill TCP connection >>>> >>>> >>>> >>>> >>>>Ben Campbell wrote: >>>> >>>> >>>>>Can we reasonably assume that all connection failures are >>>> >>>>due to NATs? >>>> >>>> >>>>>What happens if endpoints do this when the failure is caused by >>>>>something else? >>>> >>>>Good point. That could be ugly - I don't see any easy way to >>>>know when >>>>the connection fails because of NAT. Lacking that it seems >>>>infeasible to >>>>test for the NAT timeout interval. >>>> >>>>Are there any standard practices in this regard? In other words, is >>>>there a keepalive time we could use that would be sufficient >>>>most of the >>>>time and still not be too impractical to keep up? >>> >>> >>>To be safe, you need a keepalive message every 30 seconds. >> >>You can always send empty TCP packets. >> >>>Shouldn't this anyway be a relay problem? maybe a BIND is >> >>sent to the relay every x seconds. >> >>It can occur without any relays. For example, what if one >>(the active) >>endpoint is natted and the other is not? This scenario works >>with no relays. > > > We had relays in the protocol to solve such problems of NAT and firewall traversal. Lets not try to solve the problems introduced by NATS and firewalls without relays. > > MS(R)P does not support NAT and firewall traversal without relays. Am I missing something? Relays were primarily needed for when both endpoints were behind NATs. If only one is behind a NAT, you can work without a relay. Relays also helped with firewall policy that only allows connections to and/or from a particuclar address. But this is not always the case. If everyone things we can ignore NAT entirely in the base spec, then I will be happy to do so. There are some gray areas in the current draft that may or may not need to stay when relays are removed. I will follow up shortly with a list for discussion purposes. > > /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 11:03:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10660; Thu, 20 Nov 2003 11:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrHo-00059a-00; Thu, 20 Nov 2003 11:04:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrHn-00059V-00; Thu, 20 Nov 2003 11:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrHl-0003Wl-HZ; Thu, 20 Nov 2003 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrGz-0003V9-5y for simple@optimus.ietf.org; Thu, 20 Nov 2003 11:03:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10591 for ; Thu, 20 Nov 2003 11:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGw-000582-00 for simple@ietf.org; Thu, 20 Nov 2003 11:03:10 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMrGv-000577-00 for simple@ietf.org; Thu, 20 Nov 2003 11:03:09 -0500 Received: from dynamicsoft.com ([63.113.46.99]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAKG2Vca019800; Thu, 20 Nov 2003 11:02:31 -0500 (EST) Message-ID: <3FBCE58B.9020101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> <3FBCCB70.6060909@cisco.com> In-Reply-To: <3FBCCB70.6060909@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 11:02:19 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> VM is sort of in a gray area, as I think there is room for all sorts >> of interesting, non-conventional approaches. One _really_ big problem >> facing carriers these days is difficulty in deploying new services. I >> think this will be the death of some of the "conventional" telecom >> carriers in the long run. 3087 is all about trying to make it easier >> to create new (hopefully innovative) services. This was something that >> my employer (at the time of the original writing) was really worrying >> about. > > > This makes a lot of sense, and I like the approach. But I can see how a > supplier of VM systems would want to hedge its bets. This approach > depends on the user having a configurable proxy that can select among > all the VM alternatives. Much of the intelligence has been moved from > the VM to the proxy. Well, this is perhaps the essence of the long standing dispute on history vs. URI-invocation as the way to talk to voicemail systems. > > That is great if the VM provider is also the proxy provider. It is also > probably ok if all the possible proxy providers that the VM is likely to > find itself deployed with provide that functionality. But today those > aren't necessarily good assumptions. To hedge the bets, the VM provider > will probably want to have an alternative way to discriminate the > different services on its own. > > So the tricky part is getting all the pieces to a stage where they can > smoothly interoperate with one another. The other issue is that, even if you dont standardize the syntax, and leave that up to configuration, there needs to be common understanding of the semantics. Going back to the VM case, if invocation of a voicemail drop requires the VM server to get the subscriber ID, the reason for the voicemail connection, and the desired prompt, there needs to be sufficient logic in the proxy to extract that information from the request and make sure it finds its way into the r-uri. As such, I think the 3087 model only works for cases where the service invocation is parameterless; i.e., its a pure proxy function, without the need for the proxy to know how to pull information out of messages or other context, and shove it into an r-uri. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 11:04:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10721 for ; Thu, 20 Nov 2003 11:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrHw-0003Yk-OK for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 11:04:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKG4Cv9013682 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 11:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrHv-0003Yb-6a for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:04:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10660; Thu, 20 Nov 2003 11:03:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrHo-00059a-00; Thu, 20 Nov 2003 11:04:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrHn-00059V-00; Thu, 20 Nov 2003 11:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrHl-0003Wl-HZ; Thu, 20 Nov 2003 11:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrGz-0003V9-5y for simple@optimus.ietf.org; Thu, 20 Nov 2003 11:03:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10591 for ; Thu, 20 Nov 2003 11:02:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrGw-000582-00 for simple@ietf.org; Thu, 20 Nov 2003 11:03:10 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AMrGv-000577-00 for simple@ietf.org; Thu, 20 Nov 2003 11:03:09 -0500 Received: from dynamicsoft.com ([63.113.46.99]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAKG2Vca019800; Thu, 20 Nov 2003 11:02:31 -0500 (EST) Message-ID: <3FBCE58B.9020101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> <3FBCCB70.6060909@cisco.com> In-Reply-To: <3FBCCB70.6060909@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 11:02:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> VM is sort of in a gray area, as I think there is room for all sorts >> of interesting, non-conventional approaches. One _really_ big problem >> facing carriers these days is difficulty in deploying new services. I >> think this will be the death of some of the "conventional" telecom >> carriers in the long run. 3087 is all about trying to make it easier >> to create new (hopefully innovative) services. This was something that >> my employer (at the time of the original writing) was really worrying >> about. > > > This makes a lot of sense, and I like the approach. But I can see how a > supplier of VM systems would want to hedge its bets. This approach > depends on the user having a configurable proxy that can select among > all the VM alternatives. Much of the intelligence has been moved from > the VM to the proxy. Well, this is perhaps the essence of the long standing dispute on history vs. URI-invocation as the way to talk to voicemail systems. > > That is great if the VM provider is also the proxy provider. It is also > probably ok if all the possible proxy providers that the VM is likely to > find itself deployed with provide that functionality. But today those > aren't necessarily good assumptions. To hedge the bets, the VM provider > will probably want to have an alternative way to discriminate the > different services on its own. > > So the tricky part is getting all the pieces to a stage where they can > smoothly interoperate with one another. The other issue is that, even if you dont standardize the syntax, and leave that up to configuration, there needs to be common understanding of the semantics. Going back to the VM case, if invocation of a voicemail drop requires the VM server to get the subscriber ID, the reason for the voicemail connection, and the desired prompt, there needs to be sufficient logic in the proxy to extract that information from the request and make sure it finds its way into the r-uri. As such, I think the 3087 model only works for cases where the service invocation is parameterless; i.e., its a pure proxy function, without the need for the proxy to know how to pull information out of messages or other context, and shove it into an r-uri. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 11:22:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11778; Thu, 20 Nov 2003 11:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMraE-0005YR-00; Thu, 20 Nov 2003 11:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMraE-0005YO-00; Thu, 20 Nov 2003 11:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMra9-0005of-M7; Thu, 20 Nov 2003 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrZa-0005no-Dw for simple@optimus.ietf.org; Thu, 20 Nov 2003 11:22:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11751 for ; Thu, 20 Nov 2003 11:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrZZ-0005Xv-00 for simple@ietf.org; Thu, 20 Nov 2003 11:22:25 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMrZY-0005Xs-00 for simple@ietf.org; Thu, 20 Nov 2003 11:22:24 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAKGIhnG072121; Thu, 20 Nov 2003 10:18:54 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBCE95C.7030807@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> <3FBCCB70.6060909@cisco.com> In-Reply-To: <3FBCCB70.6060909@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 10:18:36 -0600 Content-Transfer-Encoding: 7bit This is becoming an abstract discussion of 3087, and I am not sure if it is of interest to the SIMPLE list. Should we keep this conversation here, or take it private? More inline: Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> VM is sort of in a gray area, as I think there is room for all sorts >> of interesting, non-conventional approaches. One _really_ big problem >> facing carriers these days is difficulty in deploying new services. I >> think this will be the death of some of the "conventional" telecom >> carriers in the long run. 3087 is all about trying to make it easier >> to create new (hopefully innovative) services. This was something that >> my employer (at the time of the original writing) was really worrying >> about. > > > This makes a lot of sense, and I like the approach. But I can see how a > supplier of VM systems would want to hedge its bets. This approach > depends on the user having a configurable proxy that can select among > all the VM alternatives. Much of the intelligence has been moved from > the VM to the proxy. This is true, but to a certain extent it is true without 3087 as well. For example, if you want to distinguish between Busy and No Answer, a proxy could either forward to a distinct URI, or it could encode an appropriate reason in a History header. Either way, it has to understand the difference. But in the 3087 case, it does not need to understand anything about VM--it just needs to understand that, under a certain set of circumstances, it forwards to a particular URI. > > That is great if the VM provider is also the proxy provider. This is not required if the customer controls the namespace. >It is also > probably ok if all the possible proxy providers that the VM is likely to > find itself deployed with provide that functionality. But today those > aren't necessarily good assumptions. To hedge the bets, the VM provider > will probably want to have an alternative way to discriminate the > different services on its own. > Right. That is why I suggested that the vendor supplied provisioning mechanism could be layered. A "raw" layer lets the customer arbitarily assign names. A higher level layer could implement a name space of the vendor's choosing (perhaps based on some convention.) > So the tricky part is getting all the pieces to a stage where they can > smoothly interoperate with one another. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 11:23:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11821 for ; Thu, 20 Nov 2003 11:23:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMraG-0005qj-ID for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 11:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGN8lY022484 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 11:23:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMraG-0005qZ-CP for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:23:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11778; Thu, 20 Nov 2003 11:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMraE-0005YR-00; Thu, 20 Nov 2003 11:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMraE-0005YO-00; Thu, 20 Nov 2003 11:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMra9-0005of-M7; Thu, 20 Nov 2003 11:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrZa-0005no-Dw for simple@optimus.ietf.org; Thu, 20 Nov 2003 11:22:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11751 for ; Thu, 20 Nov 2003 11:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrZZ-0005Xv-00 for simple@ietf.org; Thu, 20 Nov 2003 11:22:25 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMrZY-0005Xs-00 for simple@ietf.org; Thu, 20 Nov 2003 11:22:24 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAKGIhnG072121; Thu, 20 Nov 2003 10:18:54 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBCE95C.7030807@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> <3FBCCB70.6060909@cisco.com> In-Reply-To: <3FBCCB70.6060909@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 10:18:36 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is becoming an abstract discussion of 3087, and I am not sure if it is of interest to the SIMPLE list. Should we keep this conversation here, or take it private? More inline: Paul Kyzivat wrote: > > > Ben Campbell wrote: > >> >> VM is sort of in a gray area, as I think there is room for all sorts >> of interesting, non-conventional approaches. One _really_ big problem >> facing carriers these days is difficulty in deploying new services. I >> think this will be the death of some of the "conventional" telecom >> carriers in the long run. 3087 is all about trying to make it easier >> to create new (hopefully innovative) services. This was something that >> my employer (at the time of the original writing) was really worrying >> about. > > > This makes a lot of sense, and I like the approach. But I can see how a > supplier of VM systems would want to hedge its bets. This approach > depends on the user having a configurable proxy that can select among > all the VM alternatives. Much of the intelligence has been moved from > the VM to the proxy. This is true, but to a certain extent it is true without 3087 as well. For example, if you want to distinguish between Busy and No Answer, a proxy could either forward to a distinct URI, or it could encode an appropriate reason in a History header. Either way, it has to understand the difference. But in the 3087 case, it does not need to understand anything about VM--it just needs to understand that, under a certain set of circumstances, it forwards to a particular URI. > > That is great if the VM provider is also the proxy provider. This is not required if the customer controls the namespace. >It is also > probably ok if all the possible proxy providers that the VM is likely to > find itself deployed with provide that functionality. But today those > aren't necessarily good assumptions. To hedge the bets, the VM provider > will probably want to have an alternative way to discriminate the > different services on its own. > Right. That is why I suggested that the vendor supplied provisioning mechanism could be layered. A "raw" layer lets the customer arbitarily assign names. A higher level layer could implement a name space of the vendor's choosing (perhaps based on some convention.) > So the tricky part is getting all the pieces to a stage where they can > smoothly interoperate with one another. > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 11:32:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12202; Thu, 20 Nov 2003 11:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrjr-0005it-00; Thu, 20 Nov 2003 11:33:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrjr-0005iq-00; Thu, 20 Nov 2003 11:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrjp-0006Im-Ra; Thu, 20 Nov 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrji-0006IH-C6 for simple@optimus.ietf.org; Thu, 20 Nov 2003 11:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12184 for ; Thu, 20 Nov 2003 11:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrjh-0005iT-00 for simple@ietf.org; Thu, 20 Nov 2003 11:32:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMrjg-0005iQ-00 for simple@ietf.org; Thu, 20 Nov 2003 11:32:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAKGUpnG073938; Thu, 20 Nov 2003 10:30:57 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBCEC34.2090806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> <3FBCCB70.6060909@cisco.com> <3FBCE58B.9020101@dynamicsoft.com> In-Reply-To: <3FBCE58B.9020101@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 10:30:44 -0600 Content-Transfer-Encoding: 7bit As I commented in a previous note, this seems to be vearing a bit off topic for SIMPLE. I am trimming the simple list from this response. If anyone things this discussion is really relevant to the list at large, feel free to put it back. More inline: Jonathan Rosenberg wrote: > > > Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >> >>> >>> VM is sort of in a gray area, as I think there is room for all sorts >>> of interesting, non-conventional approaches. One _really_ big problem >>> facing carriers these days is difficulty in deploying new services. I >>> think this will be the death of some of the "conventional" telecom >>> carriers in the long run. 3087 is all about trying to make it easier >>> to create new (hopefully innovative) services. This was something >>> that my employer (at the time of the original writing) was really >>> worrying about. >> >> >> >> This makes a lot of sense, and I like the approach. But I can see how >> a supplier of VM systems would want to hedge its bets. This approach >> depends on the user having a configurable proxy that can select among >> all the VM alternatives. Much of the intelligence has been moved from >> the VM to the proxy. > > > Well, this is perhaps the essence of the long standing dispute on > history vs. URI-invocation as the way to talk to voicemail systems. > >> >> That is great if the VM provider is also the proxy provider. It is >> also probably ok if all the possible proxy providers that the VM is >> likely to find itself deployed with provide that functionality. But >> today those aren't necessarily good assumptions. To hedge the bets, >> the VM provider will probably want to have an alternative way to >> discriminate the different services on its own. >> >> So the tricky part is getting all the pieces to a stage where they can >> smoothly interoperate with one another. > > > The other issue is that, even if you dont standardize the syntax, and > leave that up to configuration, there needs to be common understanding > of the semantics. Going back to the VM case, if invocation of a > voicemail drop requires the VM server to get the subscriber ID, the > reason for the voicemail connection, and the desired prompt, there needs > to be sufficient logic in the proxy to extract that information from the > request and make sure it finds its way into the r-uri. > > As such, I think the 3087 model only works for cases where the service > invocation is parameterless; i.e., its a pure proxy function, without > the need for the proxy to know how to pull information out of messages > or other context, and shove it into an r-uri. The scenario you describe is _exactly_ what 3087 was intended to cover. In this particular case, the VM system associates a mailbox and menu tree entry point with a key, in the form of a specific, arbitrarily named URI. The only reason it needs to be encoded in the URI is for human-readability. I agree with your comment for things like ad-hoc list exploders, in that the list membership cannot be known in advance, so it must be encoded in someway. Also, to reiterate, there were 2 concepts in 3261. The first was to use the r-URI for this sort of things in the first place. The second was the arbitrariness of said URIs. Exploders can fit into the first concept, but not the second. So even here, 3087 partially applies. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 11:33:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12232 for ; Thu, 20 Nov 2003 11:33:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrjt-0006Ju-8B for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 11:33:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGX5dg024288 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 11:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrjt-0006Jc-4b for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 11:33:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12202; Thu, 20 Nov 2003 11:32:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrjr-0005it-00; Thu, 20 Nov 2003 11:33:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMrjr-0005iq-00; Thu, 20 Nov 2003 11:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrjp-0006Im-Ra; Thu, 20 Nov 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMrji-0006IH-C6 for simple@optimus.ietf.org; Thu, 20 Nov 2003 11:32:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12184 for ; Thu, 20 Nov 2003 11:32:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMrjh-0005iT-00 for simple@ietf.org; Thu, 20 Nov 2003 11:32:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AMrjg-0005iQ-00 for simple@ietf.org; Thu, 20 Nov 2003 11:32:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAKGUpnG073938; Thu, 20 Nov 2003 10:30:57 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBCEC34.2090806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) References: <3FBC0C66.2020906@dynamicsoft.com> <3FBCCB70.6060909@cisco.com> <3FBCE58B.9020101@dynamicsoft.com> In-Reply-To: <3FBCE58B.9020101@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 10:30:44 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit As I commented in a previous note, this seems to be vearing a bit off topic for SIMPLE. I am trimming the simple list from this response. If anyone things this discussion is really relevant to the list at large, feel free to put it back. More inline: Jonathan Rosenberg wrote: > > > Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >> >>> >>> VM is sort of in a gray area, as I think there is room for all sorts >>> of interesting, non-conventional approaches. One _really_ big problem >>> facing carriers these days is difficulty in deploying new services. I >>> think this will be the death of some of the "conventional" telecom >>> carriers in the long run. 3087 is all about trying to make it easier >>> to create new (hopefully innovative) services. This was something >>> that my employer (at the time of the original writing) was really >>> worrying about. >> >> >> >> This makes a lot of sense, and I like the approach. But I can see how >> a supplier of VM systems would want to hedge its bets. This approach >> depends on the user having a configurable proxy that can select among >> all the VM alternatives. Much of the intelligence has been moved from >> the VM to the proxy. > > > Well, this is perhaps the essence of the long standing dispute on > history vs. URI-invocation as the way to talk to voicemail systems. > >> >> That is great if the VM provider is also the proxy provider. It is >> also probably ok if all the possible proxy providers that the VM is >> likely to find itself deployed with provide that functionality. But >> today those aren't necessarily good assumptions. To hedge the bets, >> the VM provider will probably want to have an alternative way to >> discriminate the different services on its own. >> >> So the tricky part is getting all the pieces to a stage where they can >> smoothly interoperate with one another. > > > The other issue is that, even if you dont standardize the syntax, and > leave that up to configuration, there needs to be common understanding > of the semantics. Going back to the VM case, if invocation of a > voicemail drop requires the VM server to get the subscriber ID, the > reason for the voicemail connection, and the desired prompt, there needs > to be sufficient logic in the proxy to extract that information from the > request and make sure it finds its way into the r-uri. > > As such, I think the 3087 model only works for cases where the service > invocation is parameterless; i.e., its a pure proxy function, without > the need for the proxy to know how to pull information out of messages > or other context, and shove it into an r-uri. The scenario you describe is _exactly_ what 3087 was intended to cover. In this particular case, the VM system associates a mailbox and menu tree entry point with a key, in the form of a specific, arbitrarily named URI. The only reason it needs to be encoded in the URI is for human-readability. I agree with your comment for things like ad-hoc list exploders, in that the list membership cannot be known in advance, so it must be encoded in someway. Also, to reiterate, there were 2 concepts in 3261. The first was to use the r-URI for this sort of things in the first place. The second was the arbitrariness of said URIs. Exploders can fit into the first concept, but not the second. So even here, 3087 partially applies. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 13:55:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18522; Thu, 20 Nov 2003 13:55:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtyG-0000Np-00; Thu, 20 Nov 2003 13:56:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMtyG-0000Nk-00; Thu, 20 Nov 2003 13:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtyE-00016a-Mj; Thu, 20 Nov 2003 13:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtxP-00012Z-93 for simple@optimus.ietf.org; Thu, 20 Nov 2003 13:55:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18480 for ; Thu, 20 Nov 2003 13:54:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtxM-0000Ml-00 for simple@ietf.org; Thu, 20 Nov 2003 13:55:08 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AMtxM-0000MN-00 for simple@ietf.org; Thu, 20 Nov 2003 13:55:08 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 20 Nov 2003 10:54:31 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 20 Nov 2003 10:54:17 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Nov 2003 10:54:37 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 10:54:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOu+IcGUyjVrR1CTweSdoQpjxNZxwACEoRgAA4JleAAF1bwEA== From: "Orit Levin" To: , , Cc: X-OriginalArrivalTime: 20 Nov 2003 18:54:41.0487 (UTC) FILETIME=[C152FDF0:01C3AF97] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 10:54:34 -0800 Content-Transfer-Encoding: quoted-printable I believe that we should work on two sets of requirements - one in SIMPLE and one in SIPPING. SIMPLE is a very important :-) standard application on the top of SIP. This is the reason for having a dedicated WG and a dedicated set(s) of requirements. We must identify the SIMPLE requirements and then feed them back to SIPPING/SIP. If SIP manages to meet the SIMPLE requirements as a subset of the "exploder" concept - great. My quess is that it is not that simple. Thanks, Orit.=20 =20 -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Sent: Wednesday, November 19, 2003 11:40 PM To: Orit Levin; adam@dynamicsoft.com; simple@ietf.org Cc: gonzallo.camarillo@ericsson.com Subject: RE: [Simple] ad-hoc list subscriptions As I said on the mike in the SIMPLE meeting, this issue is not just limited to SUBSCRIBE, but the problem also includes MESSAGE, INVITE, etc. There are already requirements documented in http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00 .txt Should we discuss those in sipping? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 20.November.2003 03:34 > To: Adam Roach; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 >=20 > First of all, I am glad that I am not alone :-) >=20 > As a direct outcome of the discussion around the ad-hoc list topic in=20 > the SIMPLE session, I identified to myself a clear AI to come up with=20 > a requirements draft for how we distribute the dynamic information,=20 > vital for building scalable and interoperable SIMPLE infrastructures. >=20 > The user's "subscribe list" - is one simple example. > - "Single transaction mechanism" is an important requirement to me as=20 > well. - Ability to send deltas of a list is also crucial (apropos the=20 > discussed exploders' syntax). >=20 > I also see requirements for exchanging highly dynamic information=20 > between/among "Presence Servers" in optimized (e.g. compact) way. >=20 > When doing all this, I will love to reuse as many basic XML presence=20 > schemas as possible. >=20 > Creation of the requirements draft is a very high priority on my list. > I suggest that we join our efforts and create a taskforce in order to=20 > come up with suggestions/conclusions/directions... faster than=20 > usually. >=20 > I believe that we are in shortage of time here in order for the=20 > standards to be adopted by the industry. >=20 > Orit.=20 >=20 >=20 >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, November 19, 2003 3:54 PM > To: Orit Levin; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 > Orit Levin [mailto:oritl@microsoft.com] writes: >=20 > > Are we planning to automatically distribute the dynamic lists across > > the network using XCAP? >=20 > To my understanding, that was the original plan. >=20 > That said, companies working in the wireless space have been promoting > a requirement that devices that use short-lived lists must be able to=20 > send the list and the operation that uses the list in a single=20 > transaction. >=20 > I understand this requirement, and think we need some specification to > address it. I plan to submit an internet draft that expands on the=20 > ideas I have championed in this thread as soon as I have time. >=20 > Your recent draft makes it clear that using XCAP for these temporary=20 > lists doesn't meet your requirements either -- but it doesn't clarify=20 > what requirements you have on short- lived lists. What I would like to > know from you is: is this requirement (a single transaction to specify > and use a list) the same as what you need, or do you have additional=20 > and/or different requirements? >=20 > /a >=20 >=20 >=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 exim@www1.ietf.org Thu Nov 20 13:56:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18544 for ; Thu, 20 Nov 2003 13:56:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtyJ-000181-Sf for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 13:56:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKIu7xg004327 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 13:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtyJ-00017e-Nn for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 13:56:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18522; Thu, 20 Nov 2003 13:55:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtyG-0000Np-00; Thu, 20 Nov 2003 13:56:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMtyG-0000Nk-00; Thu, 20 Nov 2003 13:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtyE-00016a-Mj; Thu, 20 Nov 2003 13:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMtxP-00012Z-93 for simple@optimus.ietf.org; Thu, 20 Nov 2003 13:55:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18480 for ; Thu, 20 Nov 2003 13:54:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMtxM-0000Ml-00 for simple@ietf.org; Thu, 20 Nov 2003 13:55:08 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1AMtxM-0000MN-00 for simple@ietf.org; Thu, 20 Nov 2003 13:55:08 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 20 Nov 2003 10:54:31 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 20 Nov 2003 10:54:17 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Nov 2003 10:54:37 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 10:54:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOu+IcGUyjVrR1CTweSdoQpjxNZxwACEoRgAA4JleAAF1bwEA== From: "Orit Levin" To: , , Cc: X-OriginalArrivalTime: 20 Nov 2003 18:54:41.0487 (UTC) FILETIME=[C152FDF0:01C3AF97] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 10:54:34 -0800 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I believe that we should work on two sets of requirements - one in SIMPLE and one in SIPPING. SIMPLE is a very important :-) standard application on the top of SIP. This is the reason for having a dedicated WG and a dedicated set(s) of requirements. We must identify the SIMPLE requirements and then feed them back to SIPPING/SIP. If SIP manages to meet the SIMPLE requirements as a subset of the "exploder" concept - great. My quess is that it is not that simple. Thanks, Orit.=20 =20 -----Original Message----- From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 Sent: Wednesday, November 19, 2003 11:40 PM To: Orit Levin; adam@dynamicsoft.com; simple@ietf.org Cc: gonzallo.camarillo@ericsson.com Subject: RE: [Simple] ad-hoc list subscriptions As I said on the mike in the SIMPLE meeting, this issue is not just limited to SUBSCRIBE, but the problem also includes MESSAGE, INVITE, etc. There are already requirements documented in http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-00 .txt Should we discuss those in sipping? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Orit Levin > Sent: 20.November.2003 03:34 > To: Adam Roach; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 >=20 > First of all, I am glad that I am not alone :-) >=20 > As a direct outcome of the discussion around the ad-hoc list topic in=20 > the SIMPLE session, I identified to myself a clear AI to come up with=20 > a requirements draft for how we distribute the dynamic information,=20 > vital for building scalable and interoperable SIMPLE infrastructures. >=20 > The user's "subscribe list" - is one simple example. > - "Single transaction mechanism" is an important requirement to me as=20 > well. - Ability to send deltas of a list is also crucial (apropos the=20 > discussed exploders' syntax). >=20 > I also see requirements for exchanging highly dynamic information=20 > between/among "Presence Servers" in optimized (e.g. compact) way. >=20 > When doing all this, I will love to reuse as many basic XML presence=20 > schemas as possible. >=20 > Creation of the requirements draft is a very high priority on my list. > I suggest that we join our efforts and create a taskforce in order to=20 > come up with suggestions/conclusions/directions... faster than=20 > usually. >=20 > I believe that we are in shortage of time here in order for the=20 > standards to be adopted by the industry. >=20 > Orit.=20 >=20 >=20 >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: Wednesday, November 19, 2003 3:54 PM > To: Orit Levin; simple@ietf.org > Subject: RE: [Simple] ad-hoc list subscriptions >=20 > Orit Levin [mailto:oritl@microsoft.com] writes: >=20 > > Are we planning to automatically distribute the dynamic lists across > > the network using XCAP? >=20 > To my understanding, that was the original plan. >=20 > That said, companies working in the wireless space have been promoting > a requirement that devices that use short-lived lists must be able to=20 > send the list and the operation that uses the list in a single=20 > transaction. >=20 > I understand this requirement, and think we need some specification to > address it. I plan to submit an internet draft that expands on the=20 > ideas I have championed in this thread as soon as I have time. >=20 > Your recent draft makes it clear that using XCAP for these temporary=20 > lists doesn't meet your requirements either -- but it doesn't clarify=20 > what requirements you have on short- lived lists. What I would like to > know from you is: is this requirement (a single transaction to specify > and use a list) the same as what you need, or do you have additional=20 > and/or different requirements? >=20 > /a >=20 >=20 >=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-admin@ietf.org Thu Nov 20 15:18:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23322; Thu, 20 Nov 2003 15:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvGa-0001ea-00; Thu, 20 Nov 2003 15:19:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvGa-0001eX-00; Thu, 20 Nov 2003 15:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvGX-000765-Ng; Thu, 20 Nov 2003 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvGQ-00075f-8w for simple@optimus.ietf.org; Thu, 20 Nov 2003 15:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23308 for ; Thu, 20 Nov 2003 15:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvGO-0001e9-00 for simple@ietf.org; Thu, 20 Nov 2003 15:18:52 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AMvGO-0001dv-00 for simple@ietf.org; Thu, 20 Nov 2003 15:18:52 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAKKIA9d000778; Thu, 20 Nov 2003 14:18:10 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 14:18:09 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86640@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Orit Levin'" , hisham.khartabil@nokia.com, Adam Roach , simple@ietf.org Cc: gonzallo.camarillo@ericsson.com Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 14:18:08 -0600 Orit Levin wrote: > I believe that we should work on two sets of requirements - one in > SIMPLE and one in SIPPING. I want to make absolutely certain that we don't come up with divergent solutions for ad-hoc lists. Doing the work in two places increases the risk of that happening significantly. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 15:19:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23351 for ; Thu, 20 Nov 2003 15:19:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvGc-000779-T0 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 15:19:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKJ6iI027341 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 15:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvGc-00076u-OW for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:19:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23322; Thu, 20 Nov 2003 15:18:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvGa-0001ea-00; Thu, 20 Nov 2003 15:19:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvGa-0001eX-00; Thu, 20 Nov 2003 15:19:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvGX-000765-Ng; Thu, 20 Nov 2003 15:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvGQ-00075f-8w for simple@optimus.ietf.org; Thu, 20 Nov 2003 15:18:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23308 for ; Thu, 20 Nov 2003 15:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvGO-0001e9-00 for simple@ietf.org; Thu, 20 Nov 2003 15:18:52 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AMvGO-0001dv-00 for simple@ietf.org; Thu, 20 Nov 2003 15:18:52 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAKKIA9d000778; Thu, 20 Nov 2003 14:18:10 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 14:18:09 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86640@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Orit Levin'" , hisham.khartabil@nokia.com, Adam Roach , simple@ietf.org Cc: gonzallo.camarillo@ericsson.com Subject: RE: [Simple] ad-hoc list subscriptions MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 14:18:08 -0600 Orit Levin wrote: > I believe that we should work on two sets of requirements - one in > SIMPLE and one in SIPPING. I want to make absolutely certain that we don't come up with divergent solutions for ad-hoc lists. Doing the work in two places increases the risk of that happening significantly. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 20 15:53:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25414; Thu, 20 Nov 2003 15:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvoU-0002HW-00; Thu, 20 Nov 2003 15:54:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvoU-0002HT-00; Thu, 20 Nov 2003 15:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvoO-0001z1-QY; Thu, 20 Nov 2003 15:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvnV-0001yE-8N for simple@optimus.ietf.org; Thu, 20 Nov 2003 15:53:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25371 for ; Thu, 20 Nov 2003 15:52:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvnT-0002Gc-00 for simple@ietf.org; Thu, 20 Nov 2003 15:53:03 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AMvnT-0002Fz-00 for simple@ietf.org; Thu, 20 Nov 2003 15:53:03 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 12:52:32 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 20 Nov 2003 12:52:26 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Nov 2003 12:52:32 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 12:52:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOvo4mjJZ+0tP9AQUWZYCWYKYF67gAAYcqQ From: "Orit Levin" To: "Adam Roach" , , Cc: X-OriginalArrivalTime: 20 Nov 2003 20:52:25.0959 (UTC) FILETIME=[3413DF70:01C3AFA8] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 12:52:20 -0800 Content-Transfer-Encoding: quoted-printable Mixing SIMPLE requirements with their SIP realization or much worse - reversing the order - is what seems very wrong to me. Anyway, I am working on my AI - the SIMPLE requirements. I hope very much (obviously!!!) to use a SIP mechanism for most of them. Orit. -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com]=20 Sent: Thursday, November 20, 2003 12:18 PM To: Orit Levin; hisham.khartabil@nokia.com; Adam Roach; simple@ietf.org Cc: gonzallo.camarillo@ericsson.com Subject: RE: [Simple] ad-hoc list subscriptions Orit Levin wrote: > I believe that we should work on two sets of requirements - one in > SIMPLE and one in SIPPING. I want to make absolutely certain that we don't come up with divergent solutions for ad-hoc lists. Doing the work in two places increases the risk of that happening significantly. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 20 15:54:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25443 for ; Thu, 20 Nov 2003 15:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvoY-00023B-Or for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 15:54:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKsAsO007881 for simple-archive@odin.ietf.org; Thu, 20 Nov 2003 15:54:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvoX-00021v-5V for simple-web-archive@optimus.ietf.org; Thu, 20 Nov 2003 15:54:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25414; Thu, 20 Nov 2003 15:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvoU-0002HW-00; Thu, 20 Nov 2003 15:54:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AMvoU-0002HT-00; Thu, 20 Nov 2003 15:54:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvoO-0001z1-QY; Thu, 20 Nov 2003 15:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvnV-0001yE-8N for simple@optimus.ietf.org; Thu, 20 Nov 2003 15:53:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25371 for ; Thu, 20 Nov 2003 15:52:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMvnT-0002Gc-00 for simple@ietf.org; Thu, 20 Nov 2003 15:53:03 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1AMvnT-0002Fz-00 for simple@ietf.org; Thu, 20 Nov 2003 15:53:03 -0500 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 12:52:32 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 20 Nov 2003 12:52:26 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Nov 2003 12:52:32 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 Nov 2003 12:52:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] ad-hoc list subscriptions Message-ID: Thread-Topic: [Simple] ad-hoc list subscriptions Thread-Index: AcOvo4mjJZ+0tP9AQUWZYCWYKYF67gAAYcqQ From: "Orit Levin" To: "Adam Roach" , , Cc: X-OriginalArrivalTime: 20 Nov 2003 20:52:25.0959 (UTC) FILETIME=[3413DF70:01C3AFA8] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 20 Nov 2003 12:52:20 -0800 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mixing SIMPLE requirements with their SIP realization or much worse - reversing the order - is what seems very wrong to me. Anyway, I am working on my AI - the SIMPLE requirements. I hope very much (obviously!!!) to use a SIP mechanism for most of them. Orit. -----Original Message----- From: Adam Roach [mailto:adam@dynamicsoft.com]=20 Sent: Thursday, November 20, 2003 12:18 PM To: Orit Levin; hisham.khartabil@nokia.com; Adam Roach; simple@ietf.org Cc: gonzallo.camarillo@ericsson.com Subject: RE: [Simple] ad-hoc list subscriptions Orit Levin wrote: > I believe that we should work on two sets of requirements - one in > SIMPLE and one in SIPPING. I want to make absolutely certain that we don't come up with divergent solutions for ad-hoc lists. Doing the work in two places increases the risk of that happening significantly. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 21 06:59:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11004; Fri, 21 Nov 2003 06:59:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9xG-00018i-00; Fri, 21 Nov 2003 07:00:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN9xG-00018f-00; Fri, 21 Nov 2003 07:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9xE-00029i-4C; Fri, 21 Nov 2003 07:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9x5-00028w-Fk for simple@optimus.ietf.org; Fri, 21 Nov 2003 06:59:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10994 for ; Fri, 21 Nov 2003 06:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9x1-00018M-00 for simple@ietf.org; Fri, 21 Nov 2003 06:59:51 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AN9x0-00018I-00 for simple@ietf.org; Fri, 21 Nov 2003 06:59:50 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hALBxoV14711 for ; Fri, 21 Nov 2003 12:59:50 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id hALBxn909991 for ; Fri, 21 Nov 2003 12:59:49 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA03211 for ; Fri, 21 Nov 2003 12:59:49 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 21 Nov 2003 12:59:48 +0100 Message-ID: From: Schmidt Christian To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Simple] Content Permission in xcap-auth Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 12:59:45 +0100 Hi, version 1 of xcap auth (draft-ietf-simple-xcap-auth-usage-01) has a lot of advantages, compared with the first version. Nevertheless, I would like to discuss the following proposals for section 4.2.2.2 "Content Permissions": a) I see some redundancy in the use of the generic "show-element" permission and the permissions "show contact element", "show note". I propose to use only "show element". "contact element" as well as "note" can be addressed using the "show-element" permission as well. b) Some of these permissions represent details of the used data model/presence document. Generally the end user is not aware of this data model. E.g. tuple represents a source (hardware / software client) of presence information. The end user is normally not aware of these sources, but rather thinks in terms of "presence information elements" like "address", "note", "location", communication means,... Tuple filtering might be interesting from a subscriber point of view, but in that case it is related with "watcher filtering", and has nothing to do with "presence authorization". I propose to remove "show tuple" and "show namespace" from the list of possible permissions. c) In the former draft ("00") the list of content permissions included also "show value". I see this as an important feature since some authorization decisions will be based on the actual value of an element. An example application of the "show value" statement maybe the restriction of a particular attribute. E.g. an attribute "communication capabilities" (of type listattribute) that lists the actual supported capabilities: if I want to express that I am only reachable through "IM", it is usefull that I can filter other values (e.g. voice, video, ...) from the "communication capabilities" attribute. I propose to introduce the "show value" attribute again. tschau, Christian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 21 07:00:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11055 for ; Fri, 21 Nov 2003 07:00:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9xL-0002Aj-Ob for simple-archive@odin.ietf.org; Fri, 21 Nov 2003 07:00:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALC0BG8008348 for simple-archive@odin.ietf.org; Fri, 21 Nov 2003 07:00:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9xL-0002AZ-LR for simple-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 07:00:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11004; Fri, 21 Nov 2003 06:59:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9xG-00018i-00; Fri, 21 Nov 2003 07:00:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AN9xG-00018f-00; Fri, 21 Nov 2003 07:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9xE-00029i-4C; Fri, 21 Nov 2003 07:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN9x5-00028w-Fk for simple@optimus.ietf.org; Fri, 21 Nov 2003 06:59:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10994 for ; Fri, 21 Nov 2003 06:59:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN9x1-00018M-00 for simple@ietf.org; Fri, 21 Nov 2003 06:59:51 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AN9x0-00018I-00 for simple@ietf.org; Fri, 21 Nov 2003 06:59:50 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hALBxoV14711 for ; Fri, 21 Nov 2003 12:59:50 +0100 (MET) Received: from blues.mchh.siemens.de (blues.mchh.siemens.de [139.21.204.206]) by mail1.siemens.de (8.11.7/8.11.7) with ESMTP id hALBxn909991 for ; Fri, 21 Nov 2003 12:59:49 +0100 (MET) Received: from mchh247e.mchh.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id MAA03211 for ; Fri, 21 Nov 2003 12:59:49 +0100 (MET) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Fri, 21 Nov 2003 12:59:48 +0100 Message-ID: From: Schmidt Christian To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Simple] Content Permission in xcap-auth Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 12:59:45 +0100 Hi, version 1 of xcap auth (draft-ietf-simple-xcap-auth-usage-01) has a lot of advantages, compared with the first version. Nevertheless, I would like to discuss the following proposals for section 4.2.2.2 "Content Permissions": a) I see some redundancy in the use of the generic "show-element" permission and the permissions "show contact element", "show note". I propose to use only "show element". "contact element" as well as "note" can be addressed using the "show-element" permission as well. b) Some of these permissions represent details of the used data model/presence document. Generally the end user is not aware of this data model. E.g. tuple represents a source (hardware / software client) of presence information. The end user is normally not aware of these sources, but rather thinks in terms of "presence information elements" like "address", "note", "location", communication means,... Tuple filtering might be interesting from a subscriber point of view, but in that case it is related with "watcher filtering", and has nothing to do with "presence authorization". I propose to remove "show tuple" and "show namespace" from the list of possible permissions. c) In the former draft ("00") the list of content permissions included also "show value". I see this as an important feature since some authorization decisions will be based on the actual value of an element. An example application of the "show value" statement maybe the restriction of a particular attribute. E.g. an attribute "communication capabilities" (of type listattribute) that lists the actual supported capabilities: if I want to express that I am only reachable through "IM", it is usefull that I can filter other values (e.g. voice, video, ...) from the "communication capabilities" attribute. I propose to introduce the "show value" attribute again. tschau, Christian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 21 17:31:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08934; Fri, 21 Nov 2003 17:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJoo-0003C7-00; Fri, 21 Nov 2003 17:32:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJoo-0003C1-00; Fri, 21 Nov 2003 17:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJon-0002Wz-PW; Fri, 21 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJoa-0002WG-QE for simple@optimus.ietf.org; Fri, 21 Nov 2003 17:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08912 for ; Fri, 21 Nov 2003 17:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJoY-0003BZ-00 for simple@ietf.org; Fri, 21 Nov 2003 17:31:46 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ANJoX-0003BS-00 for simple@ietf.org; Fri, 21 Nov 2003 17:31:45 -0500 Received: from txdwillis (dhcp225.dfw.dynamicsoft.com [63.110.3.225]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hALMXKuc023718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Nov 2003 16:33:20 -0600 From: "Dean Willis" To: "'Cullen Jennings'" , Subject: RE: [Simple] Objects to NATs kill TCP connection Message-ID: <002001c3b07f$140eb830$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 16:30:32 -0600 Content-Transfer-Encoding: 7bit > > There was some assertion in the WG meeting that NATs > arbitrarily kill TCP connection and the connection needs to > be set up again. I'm sure this has happened with broken NATS > but I do not feel it is widespread and don't think we should > specifically design for it. I do think we should design for > graceful failure or recover when things in the network fail > but I don't think there is a common case of TCP failing that > involves NATs. If there were, many things that do not > automatically set up a new TCP connection, like ssh for > example, would be nearly unusable through these broken NATs. Usually when I'm sittig in a 3GPP2 meeting trying to do email and what not over an SSH tunnel I run a script on the server-side of the ssh tunnel that prints a "." every ten seconds. Why do I do this? Because if I don't, the freaking NAT box (usually a Cisco/Linksys product, set to defaults I believe) drops my port binding between mail polls, and I have to restart the ssh connection. The TCP keepalives aren't enough frequent enough to keep the NAT alive. And restarting ssh si a manual process, requiring re-entry of a key's secret. Translation: ssh IS nearly unusable with these broken NATs, unless one is keeping it almost constantly busy. MSRP sessions would have very similar properties. I believe this is demonstrably provable whenever the NAT reclamation timer is shorter than the longest-case interpacket timer, which is generally TCP keepalives at about ten minutes . . . And considering that most off-the-shelf NAT/routers seem to run reclamation timers of between thirty seconds and three minutes, it's a problem. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 21 17:32:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08977 for ; Fri, 21 Nov 2003 17:32:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJor-0002ZL-FD for simple-archive@odin.ietf.org; Fri, 21 Nov 2003 17:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMW56f009871 for simple-archive@odin.ietf.org; Fri, 21 Nov 2003 17:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJor-0002Z8-BP for simple-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 17:32:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08934; Fri, 21 Nov 2003 17:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJoo-0003C7-00; Fri, 21 Nov 2003 17:32:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANJoo-0003C1-00; Fri, 21 Nov 2003 17:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJon-0002Wz-PW; Fri, 21 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJoa-0002WG-QE for simple@optimus.ietf.org; Fri, 21 Nov 2003 17:31:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08912 for ; Fri, 21 Nov 2003 17:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJoY-0003BZ-00 for simple@ietf.org; Fri, 21 Nov 2003 17:31:46 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ANJoX-0003BS-00 for simple@ietf.org; Fri, 21 Nov 2003 17:31:45 -0500 Received: from txdwillis (dhcp225.dfw.dynamicsoft.com [63.110.3.225]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hALMXKuc023718 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Nov 2003 16:33:20 -0600 From: "Dean Willis" To: "'Cullen Jennings'" , Subject: RE: [Simple] Objects to NATs kill TCP connection Message-ID: <002001c3b07f$140eb830$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 16:30:32 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > There was some assertion in the WG meeting that NATs > arbitrarily kill TCP connection and the connection needs to > be set up again. I'm sure this has happened with broken NATS > but I do not feel it is widespread and don't think we should > specifically design for it. I do think we should design for > graceful failure or recover when things in the network fail > but I don't think there is a common case of TCP failing that > involves NATs. If there were, many things that do not > automatically set up a new TCP connection, like ssh for > example, would be nearly unusable through these broken NATs. Usually when I'm sittig in a 3GPP2 meeting trying to do email and what not over an SSH tunnel I run a script on the server-side of the ssh tunnel that prints a "." every ten seconds. Why do I do this? Because if I don't, the freaking NAT box (usually a Cisco/Linksys product, set to defaults I believe) drops my port binding between mail polls, and I have to restart the ssh connection. The TCP keepalives aren't enough frequent enough to keep the NAT alive. And restarting ssh si a manual process, requiring re-entry of a key's secret. Translation: ssh IS nearly unusable with these broken NATs, unless one is keeping it almost constantly busy. MSRP sessions would have very similar properties. I believe this is demonstrably provable whenever the NAT reclamation timer is shorter than the longest-case interpacket timer, which is generally TCP keepalives at about ten minutes . . . And considering that most off-the-shelf NAT/routers seem to run reclamation timers of between thirty seconds and three minutes, it's a problem. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 21 18:03:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10317; Fri, 21 Nov 2003 18:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKJn-0003js-00; Fri, 21 Nov 2003 18:04:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANKJn-0003jp-00; Fri, 21 Nov 2003 18:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKJl-0005Cs-N3; Fri, 21 Nov 2003 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKIw-00054L-RV for simple@optimus.ietf.org; Fri, 21 Nov 2003 18:03:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10235 for ; Fri, 21 Nov 2003 18:02:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKIu-0003is-00 for simple@ietf.org; Fri, 21 Nov 2003 18:03:08 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ANKIt-0003ip-00 for simple@ietf.org; Fri, 21 Nov 2003 18:03:07 -0500 Received: from txdwillis (dhcp225.dfw.dynamicsoft.com [63.110.3.225]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hALN4luc023805 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Nov 2003 17:04:49 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" , "'Paul Kyzivat'" Cc: "'Ben Campbell'" , "'Cullen Jennings'" , "'Adam Roach'" , , Subject: RE: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) Message-ID: <002301c3b083$7a044390$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3FBCE58B.9020101@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 17:02:00 -0600 Content-Transfer-Encoding: quoted-printable > As such, I think the 3087 model only works for cases where=20 > the service=20 > invocation is parameterless; i.e., its a pure proxy function, without=20 > the need for the proxy to know how to pull information out of=20 > messages=20 > or other context, and shove it into an r-uri. Not sur we agree here. The Proxy doesn't have to understand ANY of this. Whoever sets up the forwarding entries on the proxy has to understand = it. Case in point: If you call +1 972 473 5455, this ends up as an INVITE to sip:dwillis@dynamicsoft.com. This SIP URL is served by a proxy -- in fact, it's a really stupid = antique proxy that hasn't been updated in years. All it knows how to do is apply = a primitive version of CPL to the call . . . So this week, my CPL says "Fork to all registrations". As a result, all my phones ring -- and if none of them answer, after ten seconds, the Asterisk voice mail server that also registered to dwillis@dynamicsoft.com asnwers, and the caller gets my voice mail. Two weeks ago, my cpl said: "Fork to all registrations, and if not = answered in 8 seconds, cancel all forks and forward to phone number 2142821376", which diverted it to my cell phone, which if not answered diverts to = voice mail. Let's say I go to VoiceMailsRUs and rent a voice mail box. They tell me = the CFBNA URI for my new box is: sip:vlmner@voicemailsrus.np;boxid=3D172.98 Cool. My proxy doesn't have to understand this. All I have to do is = paste it into my cpl, and we're good to go. Now, let's say I wanted a different greeting for when my one and only = SIP phone is busy. I go back to VoiceMailsRUs, and the tell me to use the optional code GR with a value of 27 to get the nifty new "Hi, this is = Austin Powers. The swinging cat you have called is too groovy to chat right = now. Behave, and leave a message" message. So, I go change my CPL to forward calls, on "busy" at all forks, to=20 sip:vlmner@voicemailsrus.np;boxid=3D172.98,GR=3D27 And once again, despite complete ignorance of anything above the level = of SIP response codes in my proxy, I get the service I wanted. THERE IS ABSOLUTELY NO NEED TO MAKE VOICEMAILSRUS CONFORM TO ANY = EXTERNAL SEMANTIC MAP. The flip side of the rationale of 3087 is to ask "And how does = VoiceMailsRUs feel about this?" After all they're going to buy some VM boxes from Bob, = and some from Alice, and they want both brands to work with thir = provisioning system, which uses a naming convention made up a demented gnome who = retains his position by controlling incriminating photos from the 1999 company = party . . . So VoiceMailsRUs wants their provisioning system to be able to hook up = to a new VM box and say to it "Make me a new box named vlmner@vmhost;boxid=3D172.198,GR=3D27, and provision it with the = greeting APSWCYCISTGTCRNBALM.WAV". VoiceMailrsRUs does NOT want to have to change their provisioning system = to understand the behavior-specific mailbox generation semantics of Alice, = or of Bob, or Charlie, or any other smug vendor who thinks they can replace = the entire installed base at VoiceMailsRUs. And that's where 3087 came from. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 21 18:04:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10386 for ; Fri, 21 Nov 2003 18:04:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKJr-0005Gy-Ex for simple-archive@odin.ietf.org; Fri, 21 Nov 2003 18:04:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALN47DT020268 for simple-archive@odin.ietf.org; Fri, 21 Nov 2003 18:04:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKJr-0005Gp-BJ for simple-web-archive@optimus.ietf.org; Fri, 21 Nov 2003 18:04:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10317; Fri, 21 Nov 2003 18:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKJn-0003js-00; Fri, 21 Nov 2003 18:04:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ANKJn-0003jp-00; Fri, 21 Nov 2003 18:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKJl-0005Cs-N3; Fri, 21 Nov 2003 18:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKIw-00054L-RV for simple@optimus.ietf.org; Fri, 21 Nov 2003 18:03:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10235 for ; Fri, 21 Nov 2003 18:02:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKIu-0003is-00 for simple@ietf.org; Fri, 21 Nov 2003 18:03:08 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1ANKIt-0003ip-00 for simple@ietf.org; Fri, 21 Nov 2003 18:03:07 -0500 Received: from txdwillis (dhcp225.dfw.dynamicsoft.com [63.110.3.225]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hALN4luc023805 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 21 Nov 2003 17:04:49 -0600 From: "Dean Willis" To: "'Jonathan Rosenberg'" , "'Paul Kyzivat'" Cc: "'Ben Campbell'" , "'Cullen Jennings'" , "'Adam Roach'" , , Subject: RE: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) Message-ID: <002301c3b083$7a044390$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3FBCE58B.9020101@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 21 Nov 2003 17:02:00 -0600 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > As such, I think the 3087 model only works for cases where=20 > the service=20 > invocation is parameterless; i.e., its a pure proxy function, without=20 > the need for the proxy to know how to pull information out of=20 > messages=20 > or other context, and shove it into an r-uri. Not sur we agree here. The Proxy doesn't have to understand ANY of this. Whoever sets up the forwarding entries on the proxy has to understand = it. Case in point: If you call +1 972 473 5455, this ends up as an INVITE to sip:dwillis@dynamicsoft.com. This SIP URL is served by a proxy -- in fact, it's a really stupid = antique proxy that hasn't been updated in years. All it knows how to do is apply = a primitive version of CPL to the call . . . So this week, my CPL says "Fork to all registrations". As a result, all my phones ring -- and if none of them answer, after ten seconds, the Asterisk voice mail server that also registered to dwillis@dynamicsoft.com asnwers, and the caller gets my voice mail. Two weeks ago, my cpl said: "Fork to all registrations, and if not = answered in 8 seconds, cancel all forks and forward to phone number 2142821376", which diverted it to my cell phone, which if not answered diverts to = voice mail. Let's say I go to VoiceMailsRUs and rent a voice mail box. They tell me = the CFBNA URI for my new box is: sip:vlmner@voicemailsrus.np;boxid=3D172.98 Cool. My proxy doesn't have to understand this. All I have to do is = paste it into my cpl, and we're good to go. Now, let's say I wanted a different greeting for when my one and only = SIP phone is busy. I go back to VoiceMailsRUs, and the tell me to use the optional code GR with a value of 27 to get the nifty new "Hi, this is = Austin Powers. The swinging cat you have called is too groovy to chat right = now. Behave, and leave a message" message. So, I go change my CPL to forward calls, on "busy" at all forks, to=20 sip:vlmner@voicemailsrus.np;boxid=3D172.98,GR=3D27 And once again, despite complete ignorance of anything above the level = of SIP response codes in my proxy, I get the service I wanted. THERE IS ABSOLUTELY NO NEED TO MAKE VOICEMAILSRUS CONFORM TO ANY = EXTERNAL SEMANTIC MAP. The flip side of the rationale of 3087 is to ask "And how does = VoiceMailsRUs feel about this?" After all they're going to buy some VM boxes from Bob, = and some from Alice, and they want both brands to work with thir = provisioning system, which uses a naming convention made up a demented gnome who = retains his position by controlling incriminating photos from the 1999 company = party . . . So VoiceMailsRUs wants their provisioning system to be able to hook up = to a new VM box and say to it "Make me a new box named vlmner@vmhost;boxid=3D172.198,GR=3D27, and provision it with the = greeting APSWCYCISTGTCRNBALM.WAV". VoiceMailrsRUs does NOT want to have to change their provisioning system = to understand the behavior-specific mailbox generation semantics of Alice, = or of Bob, or Charlie, or any other smug vendor who thinks they can replace = the entire installed base at VoiceMailsRUs. And that's where 3087 came from. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Nov 23 19:24:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05638; Sun, 23 Nov 2003 19:24:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4WW-0001vP-00; Sun, 23 Nov 2003 19:24:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO4WV-0001vJ-00; Sun, 23 Nov 2003 19:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4WG-00027j-Em; Sun, 23 Nov 2003 19:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Vs-000245-1X for simple@optimus.ietf.org; Sun, 23 Nov 2003 19:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05616 for ; Sun, 23 Nov 2003 19:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4Vq-0001uv-00 for simple@ietf.org; Sun, 23 Nov 2003 19:23:34 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AO4Vp-0001ul-00 for simple@ietf.org; Sun, 23 Nov 2003 19:23:34 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAO0Mvj05977 for ; Sun, 23 Nov 2003 18:23:17 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XKBH6>; Mon, 24 Nov 2003 00:05:27 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00A6F90A6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Adam Roach , Jonathan Rosenberg Cc: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Question on draft-ietf-simple-presence-10 and Allow-Events Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 00:05:26 -0000 RFC 3265 section 3.3.7 indicates: Any node implementing one or more event packages SHOULD include an appropriate "Allow-Events" header indicating all supported events in all methods which initiate dialogs and their responses (such as INVITE) and OPTIONS responses. The SUBSCRIBE request to an event package surely falls into the category of a method initiating a dialog. If I look at draft-ietf-simple-presence-10 then I find no mention of the Allow-Events header, even though examples are given for the contents of SUBSCRIBE and NOTIFY methods to subscribe to the presence event package (section 8). So should these examples contain an Allow-Events header value of "presence" or is the acceptance of a subscription to a package meant to be one of the cases when the SHOULD in RFC 3265 does not apply. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Nov 23 19:24:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05657 for ; Sun, 23 Nov 2003 19:24:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4WY-00029Y-Fa for simple-archive@odin.ietf.org; Sun, 23 Nov 2003 19:24:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO0OIW9008272 for simple-archive@odin.ietf.org; Sun, 23 Nov 2003 19:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4WY-00029L-Ah for simple-web-archive@optimus.ietf.org; Sun, 23 Nov 2003 19:24:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05638; Sun, 23 Nov 2003 19:24:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4WW-0001vP-00; Sun, 23 Nov 2003 19:24:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO4WV-0001vJ-00; Sun, 23 Nov 2003 19:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4WG-00027j-Em; Sun, 23 Nov 2003 19:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO4Vs-000245-1X for simple@optimus.ietf.org; Sun, 23 Nov 2003 19:23:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05616 for ; Sun, 23 Nov 2003 19:23:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO4Vq-0001uv-00 for simple@ietf.org; Sun, 23 Nov 2003 19:23:34 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AO4Vp-0001ul-00 for simple@ietf.org; Sun, 23 Nov 2003 19:23:34 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAO0Mvj05977 for ; Sun, 23 Nov 2003 18:23:17 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XKBH6>; Mon, 24 Nov 2003 00:05:27 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00A6F90A6@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Adam Roach , Jonathan Rosenberg Cc: simple@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Question on draft-ietf-simple-presence-10 and Allow-Events Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 00:05:26 -0000 RFC 3265 section 3.3.7 indicates: Any node implementing one or more event packages SHOULD include an appropriate "Allow-Events" header indicating all supported events in all methods which initiate dialogs and their responses (such as INVITE) and OPTIONS responses. The SUBSCRIBE request to an event package surely falls into the category of a method initiating a dialog. If I look at draft-ietf-simple-presence-10 then I find no mention of the Allow-Events header, even though examples are given for the contents of SUBSCRIBE and NOTIFY methods to subscribe to the presence event package (section 8). So should these examples contain an Allow-Events header value of "presence" or is the acceptance of a subscription to a package meant to be one of the cases when the SHOULD in RFC 3265 does not apply. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 00:15:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11925; Mon, 24 Nov 2003 00:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO94u-0005oD-00; Mon, 24 Nov 2003 00:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO94t-0005oA-00; Mon, 24 Nov 2003 00:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO94r-00053p-IT; Mon, 24 Nov 2003 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO94C-00053R-H1 for simple@optimus.ietf.org; Mon, 24 Nov 2003 00:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11919 for ; Mon, 24 Nov 2003 00:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO94A-0005nL-00 for simple@ietf.org; Mon, 24 Nov 2003 00:15:18 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO949-0005mn-00 for simple@ietf.org; Mon, 24 Nov 2003 00:15:17 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO5Eoca021504; Mon, 24 Nov 2003 00:14:50 -0500 (EST) Message-ID: <3FC193C6.1020408@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Adam Roach , simple@ietf.org References: <475FF955A05DD411980D00508B6D5FB00A6F90A6@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00A6F90A6@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question on draft-ietf-simple-presence-10 and Allow-Events Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 00:14:46 -0500 Content-Transfer-Encoding: 7bit inline. Drage, Keith (Keith) wrote: > RFC 3265 section 3.3.7 indicates: > > Any node implementing one or more event packages SHOULD include an > appropriate "Allow-Events" header indicating all supported events > in all methods which initiate dialogs and their responses (such as > INVITE) and OPTIONS responses. > > The SUBSCRIBE request to an event package surely falls into the > category of a method initiating a dialog. > > If I look at draft-ietf-simple-presence-10 then I find no mention > of the Allow-Events header, even though examples are given for the > contents of SUBSCRIBE and NOTIFY methods to subscribe to the > presence event package (section 8). > > So should these examples contain an Allow-Events header value of > "presence" or is the acceptance of a subscription to a package > meant to be one of the cases when the SHOULD in RFC 3265 does not > apply. Thats a good question. I don't think the omission of Allow-Events from simple-presence was a purposeful one. However, assuming a server only supports presence, placement of the Allow-Events header field in a NOTIFY or 200 OK to SUBSCRIBE with the value of "presence" seems to be redundant. I think the text in 3.3.7 is primarily considering INVITE initiated dialogs, whereby one can learn about the packages supported by the peer. Therefore, I would be inclined to say that their omission from the examples is appropriate, and a proper case where the SHOULD doesnt apply. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 00:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11945 for ; Mon, 24 Nov 2003 00:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO94x-00054x-7x for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 00:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO5G7fW019520 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 00:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO94x-00054l-2P for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 00:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11925; Mon, 24 Nov 2003 00:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO94u-0005oD-00; Mon, 24 Nov 2003 00:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO94t-0005oA-00; Mon, 24 Nov 2003 00:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO94r-00053p-IT; Mon, 24 Nov 2003 00:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO94C-00053R-H1 for simple@optimus.ietf.org; Mon, 24 Nov 2003 00:15:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11919 for ; Mon, 24 Nov 2003 00:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO94A-0005nL-00 for simple@ietf.org; Mon, 24 Nov 2003 00:15:18 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO949-0005mn-00 for simple@ietf.org; Mon, 24 Nov 2003 00:15:17 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO5Eoca021504; Mon, 24 Nov 2003 00:14:50 -0500 (EST) Message-ID: <3FC193C6.1020408@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Adam Roach , simple@ietf.org References: <475FF955A05DD411980D00508B6D5FB00A6F90A6@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00A6F90A6@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question on draft-ietf-simple-presence-10 and Allow-Events Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 00:14:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Drage, Keith (Keith) wrote: > RFC 3265 section 3.3.7 indicates: > > Any node implementing one or more event packages SHOULD include an > appropriate "Allow-Events" header indicating all supported events > in all methods which initiate dialogs and their responses (such as > INVITE) and OPTIONS responses. > > The SUBSCRIBE request to an event package surely falls into the > category of a method initiating a dialog. > > If I look at draft-ietf-simple-presence-10 then I find no mention > of the Allow-Events header, even though examples are given for the > contents of SUBSCRIBE and NOTIFY methods to subscribe to the > presence event package (section 8). > > So should these examples contain an Allow-Events header value of > "presence" or is the acceptance of a subscription to a package > meant to be one of the cases when the SHOULD in RFC 3265 does not > apply. Thats a good question. I don't think the omission of Allow-Events from simple-presence was a purposeful one. However, assuming a server only supports presence, placement of the Allow-Events header field in a NOTIFY or 200 OK to SUBSCRIBE with the value of "presence" seems to be redundant. I think the text in 3.3.7 is primarily considering INVITE initiated dialogs, whereby one can learn about the packages supported by the peer. Therefore, I would be inclined to say that their omission from the examples is appropriate, and a proper case where the SHOULD doesnt apply. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 00:56:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13296; Mon, 24 Nov 2003 00:56:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9ib-0006Q7-00; Mon, 24 Nov 2003 00:57:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9ib-0006Q4-00; Mon, 24 Nov 2003 00:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9iW-000743-Ei; Mon, 24 Nov 2003 00:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9iA-00073m-Lz for simple@optimus.ietf.org; Mon, 24 Nov 2003 00:56:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13286 for ; Mon, 24 Nov 2003 00:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9i7-0006Pr-00 for simple@ietf.org; Mon, 24 Nov 2003 00:56:35 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9i7-0006Pa-00 for simple@ietf.org; Mon, 24 Nov 2003 00:56:35 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO5u9ca021543 for ; Mon, 24 Nov 2003 00:56:10 -0500 (EST) Message-ID: <3FC19D75.3040800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment, issue 1: conditions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 00:56:05 -0500 Content-Transfer-Encoding: 7bit Folks, This is one of a few mails I will send out regarding differences in the models and operations between the geopriv policy mechanism (which you can find at http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-00.txt ) and xcap-auth. In the current xcap-auth spec, the only place where a policy is conditionally applied is with the accept-if statement. It allows you to say, for example, that the subscription should be accepted if the watcher was anonymous: example.com In xcap-auth, conditional checks are used within the applies-to tag, so that an entire policy statement can be conditional, rather than just a piece of it. The benefit of this approach is that, once a condition (such as "if anonymous") is defined, you can make all kinds of policy choices based on it, besides accept/reject. FOr example, I can decide to give out only certain information to anonymous watchers. Moving the condition tag into applies-to would look like this: example.com Note that a statement is used if all of the conditions listed match. That is, its an AND operation, not OR. So, the question is, do we follow the geopriv model here, and make conditions part of the applies-to tag only? I believe we should, as it gives us more functionality at no cost, independent of any desire for alignment. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 00:57:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13317 for ; Mon, 24 Nov 2003 00:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9if-000764-8p for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 00:57:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO5v9cP027274 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 00:57:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9if-00075p-3V for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 00:57:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13296; Mon, 24 Nov 2003 00:56:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9ib-0006Q7-00; Mon, 24 Nov 2003 00:57:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9ib-0006Q4-00; Mon, 24 Nov 2003 00:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9iW-000743-Ei; Mon, 24 Nov 2003 00:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9iA-00073m-Lz for simple@optimus.ietf.org; Mon, 24 Nov 2003 00:56:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13286 for ; Mon, 24 Nov 2003 00:56:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9i7-0006Pr-00 for simple@ietf.org; Mon, 24 Nov 2003 00:56:35 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9i7-0006Pa-00 for simple@ietf.org; Mon, 24 Nov 2003 00:56:35 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO5u9ca021543 for ; Mon, 24 Nov 2003 00:56:10 -0500 (EST) Message-ID: <3FC19D75.3040800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment, issue 1: conditions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 00:56:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, This is one of a few mails I will send out regarding differences in the models and operations between the geopriv policy mechanism (which you can find at http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-00.txt ) and xcap-auth. In the current xcap-auth spec, the only place where a policy is conditionally applied is with the accept-if statement. It allows you to say, for example, that the subscription should be accepted if the watcher was anonymous: example.com In xcap-auth, conditional checks are used within the applies-to tag, so that an entire policy statement can be conditional, rather than just a piece of it. The benefit of this approach is that, once a condition (such as "if anonymous") is defined, you can make all kinds of policy choices based on it, besides accept/reject. FOr example, I can decide to give out only certain information to anonymous watchers. Moving the condition tag into applies-to would look like this: example.com Note that a statement is used if all of the conditions listed match. That is, its an AND operation, not OR. So, the question is, do we follow the geopriv model here, and make conditions part of the applies-to tag only? I believe we should, as it gives us more functionality at no cost, independent of any desire for alignment. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 01:03:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13467; Mon, 24 Nov 2003 01:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9pH-0006Vh-00; Mon, 24 Nov 2003 01:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9pH-0006Ve-00; Mon, 24 Nov 2003 01:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9pI-0007MH-6p; Mon, 24 Nov 2003 01:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9p0-0007L0-HM for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:03:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13447 for ; Mon, 24 Nov 2003 01:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9ox-0006V8-00 for simple@ietf.org; Mon, 24 Nov 2003 01:03:39 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9ow-0006Un-00 for simple@ietf.org; Mon, 24 Nov 2003 01:03:38 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO62pca021552 for ; Mon, 24 Nov 2003 01:02:51 -0500 (EST) Message-ID: <3FC19F06.3070507@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 2: validity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:02:46 -0500 Content-Transfer-Encoding: 7bit Folks, The geopriv policy document has a validity condition. This validity conditions defines a start and stop time wherein the policy statement applies. There are no repeats; that is, you can't have a statement be valid from 9am to 5pm every day. An example is: example.com 2003-08-15T10:20:00.000-05:00 2003-09-15T10:20:00.000-05:00 Of course, an alternative to having this validity condition is that the client simply remove the statement at the appointed time. This is more or less what we would have to do today in xcap to support any time limited policies. However, there is a privacy advantage to the geopriv approach. If, for some reason, the client got disconnected, it would not be able to go an explicitly remove the document. Thus, information might get leaked because the user couldnt reconnect to stop it from being leaked. If a validity condition is included in the statement itself, the client can be sure their privacy is maintained. Another benefit is, for cases where the client does want to set policies that apply from 9am-5pm each day, the client could reconnect each morning and simply change the valid-from and valid-until dates, instead of uploading a whole new document (which is what they would need to do now in xcap-auth). Also, to be clear, once the document is no longer valid, the server DOES NOT remove it. It stays, and is simply ignored. As such, I would propose to adopt the validity condition element. I think its valuable, independent of any desire to align with geopriv. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 01:04:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13503 for ; Mon, 24 Nov 2003 01:04:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9pL-0007PT-P2 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO643sQ028441 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9pL-0007NR-Fa for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:04:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13467; Mon, 24 Nov 2003 01:03:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9pH-0006Vh-00; Mon, 24 Nov 2003 01:03:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9pH-0006Ve-00; Mon, 24 Nov 2003 01:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9pI-0007MH-6p; Mon, 24 Nov 2003 01:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9p0-0007L0-HM for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:03:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13447 for ; Mon, 24 Nov 2003 01:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9ox-0006V8-00 for simple@ietf.org; Mon, 24 Nov 2003 01:03:39 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9ow-0006Un-00 for simple@ietf.org; Mon, 24 Nov 2003 01:03:38 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO62pca021552 for ; Mon, 24 Nov 2003 01:02:51 -0500 (EST) Message-ID: <3FC19F06.3070507@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 2: validity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:02:46 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, The geopriv policy document has a validity condition. This validity conditions defines a start and stop time wherein the policy statement applies. There are no repeats; that is, you can't have a statement be valid from 9am to 5pm every day. An example is: example.com 2003-08-15T10:20:00.000-05:00 2003-09-15T10:20:00.000-05:00 Of course, an alternative to having this validity condition is that the client simply remove the statement at the appointed time. This is more or less what we would have to do today in xcap to support any time limited policies. However, there is a privacy advantage to the geopriv approach. If, for some reason, the client got disconnected, it would not be able to go an explicitly remove the document. Thus, information might get leaked because the user couldnt reconnect to stop it from being leaked. If a validity condition is included in the statement itself, the client can be sure their privacy is maintained. Another benefit is, for cases where the client does want to set policies that apply from 9am-5pm each day, the client could reconnect each morning and simply change the valid-from and valid-until dates, instead of uploading a whole new document (which is what they would need to do now in xcap-auth). Also, to be clear, once the document is no longer valid, the server DOES NOT remove it. It stays, and is simply ignored. As such, I would propose to adopt the validity condition element. I think its valuable, independent of any desire to align with geopriv. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 01:09:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13712; Mon, 24 Nov 2003 01:09:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9v9-0006cK-00; Mon, 24 Nov 2003 01:10:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9v9-0006cH-00; Mon, 24 Nov 2003 01:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9v9-0008Fw-De; Mon, 24 Nov 2003 01:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9v6-0008FQ-UV for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:10:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13709 for ; Mon, 24 Nov 2003 01:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9v3-0006cE-00 for simple@ietf.org; Mon, 24 Nov 2003 01:09:57 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9v3-0006bv-00 for simple@ietf.org; Mon, 24 Nov 2003 01:09:57 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO69Wca021559 for ; Mon, 24 Nov 2003 01:09:32 -0500 (EST) Message-ID: <3FC1A098.6060007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 3: spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:09:28 -0500 Content-Transfer-Encoding: 7bit Folks, In the current geopriv policy document, there is a condition called "sphere". This allows a presentity to tell the server that this policy statement only applies if the current sphere of the presentity has some value. Sphere refers to an RPID element (which, afaik, is not in the current rpid document, and would need to be added for this to be useful) that describes my current situation - whether I am at work, at home, sleeping, etc. Its a dynamic context, for which my privacy rules vary as the context varies. As an example, I could define a policy thusly: example.com work and: example.com home basic This would have the effect of showing my example.com colleauges my full presence when I'm at work, but only my basic status when I'm at home. So, the question is, do we adopt this in xcap-auth? I am inclined to NOT adopt it, and indeed, to encourage geopriv to remove it, in order to reduce scope. Comments? Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 01:10:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13737 for ; Mon, 24 Nov 2003 01:10:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9vD-0008Iy-9R for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:10:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO6A7aH031918 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:10:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9vD-0008Ih-5X for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:10:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13712; Mon, 24 Nov 2003 01:09:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9v9-0006cK-00; Mon, 24 Nov 2003 01:10:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9v9-0006cH-00; Mon, 24 Nov 2003 01:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9v9-0008Fw-De; Mon, 24 Nov 2003 01:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9v6-0008FQ-UV for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:10:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13709 for ; Mon, 24 Nov 2003 01:09:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9v3-0006cE-00 for simple@ietf.org; Mon, 24 Nov 2003 01:09:57 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9v3-0006bv-00 for simple@ietf.org; Mon, 24 Nov 2003 01:09:57 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO69Wca021559 for ; Mon, 24 Nov 2003 01:09:32 -0500 (EST) Message-ID: <3FC1A098.6060007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 3: spheres Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:09:28 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, In the current geopriv policy document, there is a condition called "sphere". This allows a presentity to tell the server that this policy statement only applies if the current sphere of the presentity has some value. Sphere refers to an RPID element (which, afaik, is not in the current rpid document, and would need to be added for this to be useful) that describes my current situation - whether I am at work, at home, sleeping, etc. Its a dynamic context, for which my privacy rules vary as the context varies. As an example, I could define a policy thusly: example.com work and: example.com home basic This would have the effect of showing my example.com colleauges my full presence when I'm at work, but only my basic status when I'm at home. So, the question is, do we adopt this in xcap-auth? I am inclined to NOT adopt it, and indeed, to encourage geopriv to remove it, in order to reduce scope. Comments? Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 01:13:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13808; Mon, 24 Nov 2003 01:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9yy-0006eH-00; Mon, 24 Nov 2003 01:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9yy-0006eE-00; Mon, 24 Nov 2003 01:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9yz-0008R7-Fn; Mon, 24 Nov 2003 01:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9yS-0008QX-Du for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13799 for ; Mon, 24 Nov 2003 01:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9yP-0006e2-00 for simple@ietf.org; Mon, 24 Nov 2003 01:13:25 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9yO-0006dj-00 for simple@ietf.org; Mon, 24 Nov 2003 01:13:24 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6Cwca021562 for ; Mon, 24 Nov 2003 01:12:59 -0500 (EST) Message-ID: <3FC1A166.60901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 4: authentication Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:12:54 -0500 Content-Transfer-Encoding: 7bit Folks, Currently, xcap-auth defines an authentication condition. This allows you to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request. The geopriv policy specification currently has no such mechanism. This was discussed during the geopriv meeting in Minneapolis. If you think about it for a bit, its not clear how this would actually get used. Remember, it is end users that will set these policies. What kind of meaningful information can be provided to a user about the differences between p-asserted-id and sip-identity and digest authentication? What would make a user give permission for one type or authentication, and not another? Practically speaking, it doesnt seem like its easy to use at all. As a result, I would propose to remove the authentication condition from xcap-auth. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 01:14:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13837 for ; Mon, 24 Nov 2003 01:14:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9z2-0008TD-TJ for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:14:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO6E48G032553 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9z2-0008SF-Oi for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13808; Mon, 24 Nov 2003 01:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9yy-0006eH-00; Mon, 24 Nov 2003 01:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AO9yy-0006eE-00; Mon, 24 Nov 2003 01:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9yz-0008R7-Fn; Mon, 24 Nov 2003 01:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9yS-0008QX-Du for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13799 for ; Mon, 24 Nov 2003 01:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9yP-0006e2-00 for simple@ietf.org; Mon, 24 Nov 2003 01:13:25 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9yO-0006dj-00 for simple@ietf.org; Mon, 24 Nov 2003 01:13:24 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6Cwca021562 for ; Mon, 24 Nov 2003 01:12:59 -0500 (EST) Message-ID: <3FC1A166.60901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 4: authentication Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:12:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, Currently, xcap-auth defines an authentication condition. This allows you to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request. The geopriv policy specification currently has no such mechanism. This was discussed during the geopriv meeting in Minneapolis. If you think about it for a bit, its not clear how this would actually get used. Remember, it is end users that will set these policies. What kind of meaningful information can be provided to a user about the differences between p-asserted-id and sip-identity and digest authentication? What would make a user give permission for one type or authentication, and not another? Practically speaking, it doesnt seem like its easy to use at all. As a result, I would propose to remove the authentication condition from xcap-auth. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 01:33:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14122; Mon, 24 Nov 2003 01:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAIM-0006pK-00; Mon, 24 Nov 2003 01:34:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAIL-0006pH-00; Mon, 24 Nov 2003 01:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAIL-0000Qb-91; Mon, 24 Nov 2003 01:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAHm-0000Pl-OM for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:33:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14101 for ; Mon, 24 Nov 2003 01:33:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAHj-0006oi-00 for simple@ietf.org; Mon, 24 Nov 2003 01:33:23 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAHj-0006oP-00 for simple@ietf.org; Mon, 24 Nov 2003 01:33:23 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6Wvca021575 for ; Mon, 24 Nov 2003 01:32:58 -0500 (EST) Message-ID: <3FC1A615.1010506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 5: permission data types Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:32:53 -0500 Content-Transfer-Encoding: 7bit Folks, In the current xcap-auth spec, there is a big assumption that each permission (show-element, show-namespace, accept, accept-if, etc.) is basically a token datatype. If multiple statements apply, the overall permissions are the union across these tokens. However, in the geopriv spec, they define some additional data types. Namely, they define boolean and integer. Combining operations are then also defined for these types (logical OR for booleans, MAX operator for integers). As an example, lets say you have a permission called "accuracy": sip:fluffy@cisco.com 10 cisco.com 5 This would have the effect of granting an accuracy of 5 to everyone in Cisco, excepting fluffy who would get 10. The question, then, is whether or not to define/allow these data types and also define their combining rules. NOTE WELL - you would need to properly define your permissions such that, for an integer, a larger value is always more permissive. For booleans, TRUE would need to always be more permissive. A related issue is whether or not to convert some of our current permissions from tokens to booleans. In particular, the accept, all-content and show-note permissions would become booleans. The benefit of that is that you can explicitly say no by setting a value to false: sip:schulzrinne@columbia.edu false would explicitly reject any subscriptions from Henning. So, the question is whether or not to (1) add support for integral and boolean data types, and (2) convert the all-content, show-note and accept permissions to booleans. I believe that, independent of geopriv alignment, these are both good ideas and we should do it. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 01:34:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14165 for ; Mon, 24 Nov 2003 01:34:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAIQ-0000Rl-2a for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO6Y62d001711 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAIP-0000RW-Uu for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:34:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14122; Mon, 24 Nov 2003 01:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAIM-0006pK-00; Mon, 24 Nov 2003 01:34:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAIL-0006pH-00; Mon, 24 Nov 2003 01:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAIL-0000Qb-91; Mon, 24 Nov 2003 01:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAHm-0000Pl-OM for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:33:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14101 for ; Mon, 24 Nov 2003 01:33:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAHj-0006oi-00 for simple@ietf.org; Mon, 24 Nov 2003 01:33:23 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAHj-0006oP-00 for simple@ietf.org; Mon, 24 Nov 2003 01:33:23 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6Wvca021575 for ; Mon, 24 Nov 2003 01:32:58 -0500 (EST) Message-ID: <3FC1A615.1010506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 5: permission data types Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:32:53 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, In the current xcap-auth spec, there is a big assumption that each permission (show-element, show-namespace, accept, accept-if, etc.) is basically a token datatype. If multiple statements apply, the overall permissions are the union across these tokens. However, in the geopriv spec, they define some additional data types. Namely, they define boolean and integer. Combining operations are then also defined for these types (logical OR for booleans, MAX operator for integers). As an example, lets say you have a permission called "accuracy": sip:fluffy@cisco.com 10 cisco.com 5 This would have the effect of granting an accuracy of 5 to everyone in Cisco, excepting fluffy who would get 10. The question, then, is whether or not to define/allow these data types and also define their combining rules. NOTE WELL - you would need to properly define your permissions such that, for an integer, a larger value is always more permissive. For booleans, TRUE would need to always be more permissive. A related issue is whether or not to convert some of our current permissions from tokens to booleans. In particular, the accept, all-content and show-note permissions would become booleans. The benefit of that is that you can explicitly say no by setting a value to false: sip:schulzrinne@columbia.edu false would explicitly reject any subscriptions from Henning. So, the question is whether or not to (1) add support for integral and boolean data types, and (2) convert the all-content, show-note and accept permissions to booleans. I believe that, independent of geopriv alignment, these are both good ideas and we should do it. Comments? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 01:42:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14426; Mon, 24 Nov 2003 01:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAR2-0006vF-00; Mon, 24 Nov 2003 01:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAR2-0006vC-00; Mon, 24 Nov 2003 01:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAR3-0001O0-Cc; Mon, 24 Nov 2003 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAQn-0001NE-1g for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:42:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14414 for ; Mon, 24 Nov 2003 01:42:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAQj-0006uv-00 for simple@ietf.org; Mon, 24 Nov 2003 01:42:41 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAQj-0006ua-00 for simple@ietf.org; Mon, 24 Nov 2003 01:42:41 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6gGca021579 for ; Mon, 24 Nov 2003 01:42:16 -0500 (EST) Message-ID: <3FC1A843.9020109@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 6: subscription confirmation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:42:11 -0500 Content-Transfer-Encoding: 7bit Folks, In the current xcap-auth model, there is an important assumption that if there are no statements that apply to a watcher, the implication is that their subscription is pending, and that the presentity should get a winfo notification about the fact that its pending, so that they can make a policy decision. This assumption is based on another assumption I made, which is that the ONLY reason that a watcher would go into the pending state, is if you have not specified a policy for them yet. However, geopriv doesnt make this assumption. They have an element called "confirm-subscription". If present, it means that the presentity should be alerted about the subscription, and asked for confirmation. As a result, there is a way to EXPLICITLY say "let me know if this person subscribes". I think there are legitimate use cases for this, which came up during the geopriv meeting in Minneapolis. In particular, I may grant my boss permission to subscribe during the day, but during the evening, I want to be prompted each time, to see if I will grant it or not. To do this, we could follow their lead and add a "confirm-subscription" boolean, which would explicitly place the watcher into the pending state. I think this makes sense, and I would suggest adding this capability to xcap-auth. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 01:43:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14457 for ; Mon, 24 Nov 2003 01:43:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAR6-0001Q3-73 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO6h4ab005449 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAR6-0001Po-3a for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:43:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14426; Mon, 24 Nov 2003 01:42:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAR2-0006vF-00; Mon, 24 Nov 2003 01:43:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAR2-0006vC-00; Mon, 24 Nov 2003 01:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAR3-0001O0-Cc; Mon, 24 Nov 2003 01:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAQn-0001NE-1g for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:42:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14414 for ; Mon, 24 Nov 2003 01:42:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAQj-0006uv-00 for simple@ietf.org; Mon, 24 Nov 2003 01:42:41 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAQj-0006ua-00 for simple@ietf.org; Mon, 24 Nov 2003 01:42:41 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6gGca021579 for ; Mon, 24 Nov 2003 01:42:16 -0500 (EST) Message-ID: <3FC1A843.9020109@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 6: subscription confirmation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:42:11 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, In the current xcap-auth model, there is an important assumption that if there are no statements that apply to a watcher, the implication is that their subscription is pending, and that the presentity should get a winfo notification about the fact that its pending, so that they can make a policy decision. This assumption is based on another assumption I made, which is that the ONLY reason that a watcher would go into the pending state, is if you have not specified a policy for them yet. However, geopriv doesnt make this assumption. They have an element called "confirm-subscription". If present, it means that the presentity should be alerted about the subscription, and asked for confirmation. As a result, there is a way to EXPLICITLY say "let me know if this person subscribes". I think there are legitimate use cases for this, which came up during the geopriv meeting in Minneapolis. In particular, I may grant my boss permission to subscribe during the day, but during the evening, I want to be prompted each time, to see if I will grant it or not. To do this, we could follow their lead and add a "confirm-subscription" boolean, which would explicitly place the watcher into the pending state. I think this makes sense, and I would suggest adding this capability to xcap-auth. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 01:49:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14633; Mon, 24 Nov 2003 01:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAXq-000726-00; Mon, 24 Nov 2003 01:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAXp-000723-00; Mon, 24 Nov 2003 01:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAXq-0001aV-6j; Mon, 24 Nov 2003 01:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAXJ-0001ZK-Od for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:49:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14619 for ; Mon, 24 Nov 2003 01:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAXG-00071b-00 for simple@ietf.org; Mon, 24 Nov 2003 01:49:26 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAXF-000712-00 for simple@ietf.org; Mon, 24 Nov 2003 01:49:25 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6n0ca021582 for ; Mon, 24 Nov 2003 01:49:00 -0500 (EST) Message-ID: <3FC1A9D7.2010105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 7: actions and transformations Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:48:55 -0500 Content-Transfer-Encoding: 7bit Folks, In the current xcap-auth document, the spec describes two different types of permissions. These are "acceptance" permissions and "content" permissions. The former are permissions about who can or cannot subscribe in the first place. The latter are permissions about what they will see when they do subscribe. In geopriv, they instead have "actions" and "transformations". The actions are things to do - accept a subscription, confirm a subscription. Other possible actions in the future might be to log the event, send an IM, etc. Then "transformations" specify operations on the data that the watcher will receive. This is equivalent to what we call content permissions. The geopriv document separates these types of elements within the document through an enclosing "actions" and "transformations" tag. In xcap-auth, its flat, and no syntactic distinction is made between the two types. I would propose we adopt the geopriv terminology and xml syntax. Using the syntax has the benefit that, with the xcap protocol, you could change all of the actions or all of the transformations in one operation. The terminology is apparently more consistent with other policy languages that exist. As an example of what this change would mean, here is a document in the current xcap-auth format: sip:joe@example.com rpid and with this change, would look like: sip:joe@example.com rpid Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 01:50:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14654 for ; Mon, 24 Nov 2003 01:50:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAXu-0001bJ-1R for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO6o6Vh006151 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 01:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAXt-0001b8-U5 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 01:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14633; Mon, 24 Nov 2003 01:49:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAXq-000726-00; Mon, 24 Nov 2003 01:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAXp-000723-00; Mon, 24 Nov 2003 01:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAXq-0001aV-6j; Mon, 24 Nov 2003 01:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAXJ-0001ZK-Od for simple@optimus.ietf.org; Mon, 24 Nov 2003 01:49:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14619 for ; Mon, 24 Nov 2003 01:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAXG-00071b-00 for simple@ietf.org; Mon, 24 Nov 2003 01:49:26 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAXF-000712-00 for simple@ietf.org; Mon, 24 Nov 2003 01:49:25 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO6n0ca021582 for ; Mon, 24 Nov 2003 01:49:00 -0500 (EST) Message-ID: <3FC1A9D7.2010105@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 7: actions and transformations Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 01:48:55 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, In the current xcap-auth document, the spec describes two different types of permissions. These are "acceptance" permissions and "content" permissions. The former are permissions about who can or cannot subscribe in the first place. The latter are permissions about what they will see when they do subscribe. In geopriv, they instead have "actions" and "transformations". The actions are things to do - accept a subscription, confirm a subscription. Other possible actions in the future might be to log the event, send an IM, etc. Then "transformations" specify operations on the data that the watcher will receive. This is equivalent to what we call content permissions. The geopriv document separates these types of elements within the document through an enclosing "actions" and "transformations" tag. In xcap-auth, its flat, and no syntactic distinction is made between the two types. I would propose we adopt the geopriv terminology and xml syntax. Using the syntax has the benefit that, with the xcap protocol, you could change all of the actions or all of the transformations in one operation. The terminology is apparently more consistent with other policy languages that exist. As an example of what this change would mean, here is a document in the current xcap-auth format: sip:joe@example.com rpid and with this change, would look like: sip:joe@example.com rpid Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 02:02:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17841; Mon, 24 Nov 2003 02:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAkR-0007BT-00; Mon, 24 Nov 2003 02:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAkR-0007BQ-00; Mon, 24 Nov 2003 02:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAkP-0002M0-0K; Mon, 24 Nov 2003 02:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAk5-0002L3-Lb for simple@optimus.ietf.org; Mon, 24 Nov 2003 02:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17389 for ; Mon, 24 Nov 2003 02:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAk2-0007BH-00 for simple@ietf.org; Mon, 24 Nov 2003 02:02:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAk1-0007B3-00 for simple@ietf.org; Mon, 24 Nov 2003 02:02:37 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO72Cca021586 for ; Mon, 24 Nov 2003 02:02:12 -0500 (EST) Message-ID: <3FC1ACEF.2060703@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 8: exceptions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 02:02:07 -0500 Content-Transfer-Encoding: 7bit This issue consumed a lot of discussion during the Minneapolis IETF. The current xcap-auth specification adds support for exceptions within the applies-to statements. This allows for a way to say that a statement applies to all the users in a domain or list EXCEPT the listed set of users. This is useful for specifying things like "I want to grant permission to everyone in dynamicsoft.com except for Bob". Presumably Bob is an annoying guy and I just don't want to grant him permission. Now, a few points need to be made clear about the exceptions processing. Firstly, having things like this: sip:joe@example.com is completely useless. The reason is that it is really easy to obtain new names from many namespace providers. As a result, you may thikn you are blocking Joe, but he just goes off, gets a new URI from yahoo, and your permission statement is useless. Indeed, the entire notion of except clauses is only useful if you assume that there are cases where it is hard to obtain new identifiers. There was some dispute about whether this is a good assumnption or not. I, and some others, do believe that in many enterprises, it is a good assumption that obtaining a new enterprise identifier is not easy. A second point on exceptions. If an exception represents a list, and you can't dereference that list, then you have to drop the entire permission statement. This is to ensure privacy-safety, so that information is not leaked under any failure condition. Finally, it needs to be clarified that exceptions still result in additive permissions. So, for example, if I have two staements like this: example.com sip:sally@example.com and example.com sip:bob@example.com That if EITHER Sally or Bob subscribes, they will be granted permission to subscribe. Thats because, if Bob subscribes, the first policy statement applies to him, resulting in his subscription being accepted. If Sally subscribes, the second applies to her, and her subscription is accepted. If you try and make except clauses carry across permission statements, you end up in a place where these statements are no longer additive, and you are not privacy safe anymore. Now, even given these clarifications, the geopriv group is not planning on specifying an except condition at this time. Though they consider it useful, its been ruled out of scope for the initial policy document. Thus, if we wish to align, we would need to also rule it out of scope in the initial version of the specification. That does not mean it could never be done; indeed, it would be my proposal to more or less immediately have a draft defining it, and progress this just behind the main specs. IMHO, it is worth getting alignment to let this feature move forward in a separate specification, behind the main one. Comments and thoughts? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 02:03:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18421 for ; Mon, 24 Nov 2003 02:03:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAkX-0002Nu-Qn for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 02:03:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO739lu009165 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 02:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAkW-0002Nk-9a for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 02:03:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17841; Mon, 24 Nov 2003 02:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAkR-0007BT-00; Mon, 24 Nov 2003 02:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOAkR-0007BQ-00; Mon, 24 Nov 2003 02:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAkP-0002M0-0K; Mon, 24 Nov 2003 02:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOAk5-0002L3-Lb for simple@optimus.ietf.org; Mon, 24 Nov 2003 02:02:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17389 for ; Mon, 24 Nov 2003 02:02:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOAk2-0007BH-00 for simple@ietf.org; Mon, 24 Nov 2003 02:02:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOAk1-0007B3-00 for simple@ietf.org; Mon, 24 Nov 2003 02:02:37 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO72Cca021586 for ; Mon, 24 Nov 2003 02:02:12 -0500 (EST) Message-ID: <3FC1ACEF.2060703@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 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 Content-Transfer-Encoding: 7bit Subject: [Simple] xcap/geopriv alignment issue 8: exceptions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 02:02:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This issue consumed a lot of discussion during the Minneapolis IETF. The current xcap-auth specification adds support for exceptions within the applies-to statements. This allows for a way to say that a statement applies to all the users in a domain or list EXCEPT the listed set of users. This is useful for specifying things like "I want to grant permission to everyone in dynamicsoft.com except for Bob". Presumably Bob is an annoying guy and I just don't want to grant him permission. Now, a few points need to be made clear about the exceptions processing. Firstly, having things like this: sip:joe@example.com is completely useless. The reason is that it is really easy to obtain new names from many namespace providers. As a result, you may thikn you are blocking Joe, but he just goes off, gets a new URI from yahoo, and your permission statement is useless. Indeed, the entire notion of except clauses is only useful if you assume that there are cases where it is hard to obtain new identifiers. There was some dispute about whether this is a good assumnption or not. I, and some others, do believe that in many enterprises, it is a good assumption that obtaining a new enterprise identifier is not easy. A second point on exceptions. If an exception represents a list, and you can't dereference that list, then you have to drop the entire permission statement. This is to ensure privacy-safety, so that information is not leaked under any failure condition. Finally, it needs to be clarified that exceptions still result in additive permissions. So, for example, if I have two staements like this: example.com sip:sally@example.com and example.com sip:bob@example.com That if EITHER Sally or Bob subscribes, they will be granted permission to subscribe. Thats because, if Bob subscribes, the first policy statement applies to him, resulting in his subscription being accepted. If Sally subscribes, the second applies to her, and her subscription is accepted. If you try and make except clauses carry across permission statements, you end up in a place where these statements are no longer additive, and you are not privacy safe anymore. Now, even given these clarifications, the geopriv group is not planning on specifying an except condition at this time. Though they consider it useful, its been ruled out of scope for the initial policy document. Thus, if we wish to align, we would need to also rule it out of scope in the initial version of the specification. That does not mean it could never be done; indeed, it would be my proposal to more or less immediately have a draft defining it, and progress this just behind the main specs. IMHO, it is worth getting alignment to let this feature move forward in a separate specification, behind the main one. Comments and thoughts? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 06:50:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04690; Mon, 24 Nov 2003 06:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFF8-0002lY-00; Mon, 24 Nov 2003 06:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOFF8-0002lV-00; Mon, 24 Nov 2003 06:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFF6-0003Lv-9x; Mon, 24 Nov 2003 06:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFEE-0003KO-6C for simple@optimus.ietf.org; Mon, 24 Nov 2003 06:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04675 for ; Mon, 24 Nov 2003 06:49:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFE9-0002l0-00 for simple@ietf.org; Mon, 24 Nov 2003 06:50:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOFE9-0002kv-00 for simple@ietf.org; Mon, 24 Nov 2003 06:50:01 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOBo1A14066 for ; Mon, 24 Nov 2003 13:50:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 13:50:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:50:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment, issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B104@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment, issue 1: conditions Thread-Index: AcOyT9Jz6hdsvcURTDejG8LUHr/1QAAKnuEw To: , X-OriginalArrivalTime: 24 Nov 2003 11:50:01.0034 (UTC) FILETIME=[17716AA0:01C3B281] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 13:50:00 +0200 Content-Transfer-Encoding: quoted-printable Since we are mirroring a lot of geopriv's schema; I have a suggestion: Why don't we define a common schema for both using one xml namespace. It = can have all the needed elements like , , = etc. xcap-auth specific elements can then be specified as extensions defined. = Geopriv can do the same with their specific elements. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 06:51:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04711 for ; Mon, 24 Nov 2003 06:51:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFFD-0003Mp-Gp for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 06:51:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOBp7mh012937 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 06:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFFD-0003Ma-C1 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 06:51:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04690; Mon, 24 Nov 2003 06:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFF8-0002lY-00; Mon, 24 Nov 2003 06:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOFF8-0002lV-00; Mon, 24 Nov 2003 06:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFF6-0003Lv-9x; Mon, 24 Nov 2003 06:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFEE-0003KO-6C for simple@optimus.ietf.org; Mon, 24 Nov 2003 06:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04675 for ; Mon, 24 Nov 2003 06:49:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFE9-0002l0-00 for simple@ietf.org; Mon, 24 Nov 2003 06:50:01 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOFE9-0002kv-00 for simple@ietf.org; Mon, 24 Nov 2003 06:50:01 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOBo1A14066 for ; Mon, 24 Nov 2003 13:50:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 13:50:01 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:50:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment, issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B104@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment, issue 1: conditions Thread-Index: AcOyT9Jz6hdsvcURTDejG8LUHr/1QAAKnuEw To: , X-OriginalArrivalTime: 24 Nov 2003 11:50:01.0034 (UTC) FILETIME=[17716AA0:01C3B281] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 13:50:00 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Since we are mirroring a lot of geopriv's schema; I have a suggestion: Why don't we define a common schema for both using one xml namespace. It = can have all the needed elements like , , = etc. xcap-auth specific elements can then be specified as extensions defined. = Geopriv can do the same with their specific elements. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 06:54:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04785; Mon, 24 Nov 2003 06:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFJ2-0002nU-00; Mon, 24 Nov 2003 06:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOFJ2-0002nR-00; Mon, 24 Nov 2003 06:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFJ0-0003WG-Lp; Mon, 24 Nov 2003 06:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFIL-0003Uu-D4 for simple@optimus.ietf.org; Mon, 24 Nov 2003 06:54:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04771 for ; Mon, 24 Nov 2003 06:54:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFIH-0002mn-00 for simple@ietf.org; Mon, 24 Nov 2003 06:54:17 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOFIG-0002mk-00 for simple@ietf.org; Mon, 24 Nov 2003 06:54:16 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOBsH604597 for ; Mon, 24 Nov 2003 13:54:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 13:54:16 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:54:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:54:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797428@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOyUlEmisai2IDlRAqs0RcuDYO2TwALt4jA To: , X-OriginalArrivalTime: 24 Nov 2003 11:54:15.0579 (UTC) FILETIME=[AF29E6B0:01C3B281] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 13:54:15 +0200 Content-Transfer-Encoding: quoted-printable Can the user at least have a say in accepting or rejecting the = subscription based on the availability of any authentication type. Eg: A = user can reject subscriptions that are not authenticated in any way and = accept subscriptions that are authenticated, regardless of = authentication type. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 24.November.2003 08:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Folks, >=20 > Currently, xcap-auth defines an authentication condition. This allows=20 > you to decide whether to accept or reject a subscription based on the=20 > type of authentication used in the SUBSCRIBE request. >=20 > The geopriv policy specification currently has no such mechanism. >=20 > This was discussed during the geopriv meeting in Minneapolis. If you=20 > think about it for a bit, its not clear how this would actually get=20 > used. Remember, it is end users that will set these policies. What=20 > kind of meaningful information can be provided to a user about the=20 > differences between p-asserted-id and sip-identity and digest=20 > authentication? What would make a user give permission for=20 > one type or=20 > authentication, and not another? Practically speaking, it doesnt seem=20 > like its easy to use at all. >=20 > As a result, I would propose to remove the authentication condition=20 > from xcap-auth. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=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 exim@www1.ietf.org Mon Nov 24 06:55:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04817 for ; Mon, 24 Nov 2003 06:55:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFJ7-0003aS-K4 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 06:55:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOBt94K013788 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 06:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFJ7-0003aJ-F5 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 06:55:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04785; Mon, 24 Nov 2003 06:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFJ2-0002nU-00; Mon, 24 Nov 2003 06:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOFJ2-0002nR-00; Mon, 24 Nov 2003 06:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFJ0-0003WG-Lp; Mon, 24 Nov 2003 06:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOFIL-0003Uu-D4 for simple@optimus.ietf.org; Mon, 24 Nov 2003 06:54:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04771 for ; Mon, 24 Nov 2003 06:54:04 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOFIH-0002mn-00 for simple@ietf.org; Mon, 24 Nov 2003 06:54:17 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOFIG-0002mk-00 for simple@ietf.org; Mon, 24 Nov 2003 06:54:16 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOBsH604597 for ; Mon, 24 Nov 2003 13:54:17 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 13:54:16 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:54:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 13:54:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797428@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOyUlEmisai2IDlRAqs0RcuDYO2TwALt4jA To: , X-OriginalArrivalTime: 24 Nov 2003 11:54:15.0579 (UTC) FILETIME=[AF29E6B0:01C3B281] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 13:54:15 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Can the user at least have a say in accepting or rejecting the = subscription based on the availability of any authentication type. Eg: A = user can reject subscriptions that are not authenticated in any way and = accept subscriptions that are authenticated, regardless of = authentication type. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 24.November.2003 08:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Folks, >=20 > Currently, xcap-auth defines an authentication condition. This allows=20 > you to decide whether to accept or reject a subscription based on the=20 > type of authentication used in the SUBSCRIBE request. >=20 > The geopriv policy specification currently has no such mechanism. >=20 > This was discussed during the geopriv meeting in Minneapolis. If you=20 > think about it for a bit, its not clear how this would actually get=20 > used. Remember, it is end users that will set these policies. What=20 > kind of meaningful information can be provided to a user about the=20 > differences between p-asserted-id and sip-identity and digest=20 > authentication? What would make a user give permission for=20 > one type or=20 > authentication, and not another? Practically speaking, it doesnt seem=20 > like its easy to use at all. >=20 > As a result, I would propose to remove the authentication condition=20 > from xcap-auth. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=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-admin@ietf.org Mon Nov 24 08:40:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07691; Mon, 24 Nov 2003 08:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxb-0004yg-00; Mon, 24 Nov 2003 08:41:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOGxb-0004yd-00; Mon, 24 Nov 2003 08:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxZ-0001Yt-Fg; Mon, 24 Nov 2003 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxI-0001Vr-M9 for simple@optimus.ietf.org; Mon, 24 Nov 2003 08:40:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07595 for ; Mon, 24 Nov 2003 08:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxH-0004w4-00 for simple@ietf.org; Mon, 24 Nov 2003 08:40:43 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxG-0004vo-00 for simple@ietf.org; Mon, 24 Nov 2003 08:40:42 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hAODeCYb004391 for ; Mon, 24 Nov 2003 07:40:12 -0600 (CST) Received: from ericsson.com (rvi2-92-57.sw.ericsson.se [153.88.92.57]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XH3Y0VGB; Mon, 24 Nov 2003 07:40:05 -0600 Message-ID: <3FC20A38.4060202@ericsson.com> X-Sybari-Trust: 183417f4 6fa56f4d 0641cb9c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] [Fwd: Exploders anad ad-hoc lists] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:40:08 +0200 Content-Transfer-Encoding: 7bit Folks, let's try to discuss this topic in the SIPPING mailing list. Thanks, Gonzalo -------- Original Message -------- Subject: Exploders anad ad-hoc lists Date: Mon, 24 Nov 2003 15:39:06 +0200 From: Gonzalo Camarillo To: sipping CC: Adam Roach , Aki.Niemi@nokia.com, Hisham.Khartabil@nokia.com, Markus.Isomaki@nokia.com Folks, we have just submitted three drafts about exploders and ad-hoc lists. We have added more requirements to the following draft. The new requirements were mainly discussed in the SIMPLE mailing list. http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders-01.txt The following draft describes how to carry lists of URIs in SIP requests. It is not a finished draft. It is intended to trigger discussions on this topic to see whether this is a step the right direction. http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-uri-list-00.txt The following draft defines a new method called EXPLODE. EXPLODE does the same as REFER. That is, it tells a UA to send a request somewhere. The differences are that EXPLODE accepts more than one destination (REFER carries a single Refer-To header field) and that EXPLODE does not establish implicit subscriptions of any type. This draft is also intended to trigger discussions within the WG. http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-explode-method-00.txt Let's try to keep discussions about this topic in the SIPPING mailing list. I will forward this mail to the SIMPLE mailing list to let them know. Comments are welcome, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 08:41:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07827 for ; Mon, 24 Nov 2003 08:41:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxd-0001ez-AH for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 08:41:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODf5ZM006375 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 08:41:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxd-0001ek-6f for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07691; Mon, 24 Nov 2003 08:40:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxb-0004yg-00; Mon, 24 Nov 2003 08:41:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOGxb-0004yd-00; Mon, 24 Nov 2003 08:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxZ-0001Yt-Fg; Mon, 24 Nov 2003 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGxI-0001Vr-M9 for simple@optimus.ietf.org; Mon, 24 Nov 2003 08:40:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07595 for ; Mon, 24 Nov 2003 08:40:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxH-0004w4-00 for simple@ietf.org; Mon, 24 Nov 2003 08:40:43 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AOGxG-0004vo-00 for simple@ietf.org; Mon, 24 Nov 2003 08:40:42 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hAODeCYb004391 for ; Mon, 24 Nov 2003 07:40:12 -0600 (CST) Received: from ericsson.com (rvi2-92-57.sw.ericsson.se [153.88.92.57]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XH3Y0VGB; Mon, 24 Nov 2003 07:40:05 -0600 Message-ID: <3FC20A38.4060202@ericsson.com> X-Sybari-Trust: 183417f4 6fa56f4d 0641cb9c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] [Fwd: Exploders anad ad-hoc lists] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:40:08 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, let's try to discuss this topic in the SIPPING mailing list. Thanks, Gonzalo -------- Original Message -------- Subject: Exploders anad ad-hoc lists Date: Mon, 24 Nov 2003 15:39:06 +0200 From: Gonzalo Camarillo To: sipping CC: Adam Roach , Aki.Niemi@nokia.com, Hisham.Khartabil@nokia.com, Markus.Isomaki@nokia.com Folks, we have just submitted three drafts about exploders and ad-hoc lists. We have added more requirements to the following draft. The new requirements were mainly discussed in the SIMPLE mailing list. http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-exploders-01.txt The following draft describes how to carry lists of URIs in SIP requests. It is not a finished draft. It is intended to trigger discussions on this topic to see whether this is a step the right direction. http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-uri-list-00.txt The following draft defines a new method called EXPLODE. EXPLODE does the same as REFER. That is, it tells a UA to send a request somewhere. The differences are that EXPLODE accepts more than one destination (REFER carries a single Refer-To header field) and that EXPLODE does not establish implicit subscriptions of any type. This draft is also intended to trigger discussions within the WG. http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-explode-method-00.txt Let's try to keep discussions about this topic in the SIPPING mailing list. I will forward this mail to the SIMPLE mailing list to let them know. Comments are welcome, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 08:46:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07990; Mon, 24 Nov 2003 08:46:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOH34-00054d-00; Mon, 24 Nov 2003 08:46:42 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOGxZ-0004vi-00; Mon, 24 Nov 2003 08:41:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOGhX-0001pI-6i; Mon, 24 Nov 2003 08:24:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhA-0007PH-TZ; Mon, 24 Nov 2003 08:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOG7P-000664-6a for simple@optimus.ietf.org; Mon, 24 Nov 2003 07:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05916 for ; Mon, 24 Nov 2003 07:46:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOG7N-0003k3-00 for simple@ietf.org; Mon, 24 Nov 2003 07:47:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOG7M-0003jz-00 for simple@ietf.org; Mon, 24 Nov 2003 07:47:04 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOCl2A04390 for ; Mon, 24 Nov 2003 14:47:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 14:47:02 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 14:47:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B105@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOyWQpLMDZBrDr0S/6Ngtrw7sOB7gALzfAw To: , X-OriginalArrivalTime: 24 Nov 2003 12:47:02.0309 (UTC) FILETIME=[0EAE8D50:01C3B289] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:47:01 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 24.November.2003 09:02 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > This issue consumed a lot of discussion during the Minneapolis IETF. >=20 > The current xcap-auth specification adds support for=20 > exceptions within=20 > the applies-to statements. This allows for a way to say that a=20 > statement applies to all the users in a domain or list EXCEPT the=20 > listed set of users. This is useful for specifying things=20 > like "I want=20 > to grant permission to everyone in dynamicsoft.com except for Bob".=20 > Presumably Bob is an annoying guy and I just don't want to grant him=20 > permission. >=20 > Now, a few points need to be made clear about the exceptions=20 > processing. >=20 > Firstly, having things like this: >=20 > > > > sip:joe@example.com > > >=20 > is completely useless. The reason is that it is really easy to obtain=20 > new names from many namespace providers. As a result, you may thikn=20 > you are blocking Joe, but he just goes off, gets a new URI=20 > from yahoo,=20 > and your permission statement is useless. >=20 > Indeed, the entire notion of except clauses is only useful if you=20 > assume that there are cases where it is hard to obtain new=20 > identifiers. There was some dispute about whether this is a good=20 > assumnption or not. I, and some others, do believe that in many=20 > enterprises, it is a good assumption that obtaining a new enterprise=20 > identifier is not easy. >=20 > A second point on exceptions. If an exception represents a list, and=20 > you can't dereference that list, then you have to drop the entire=20 > permission statement. This is to ensure privacy-safety, so that=20 > information is not leaked under any failure condition. >=20 > Finally, it needs to be clarified that exceptions still result in=20 > additive permissions. So, for example, if I have two=20 > staements like this: >=20 > > example.com > > sip:sally@example.com > > >=20 > >=20 > and >=20 > > example.com > > sip:bob@example.com > > >=20 > >=20 I don't see why someone would compose 2 permissions for the same domain. = What is a scenario for this? >=20 >=20 > That if EITHER Sally or Bob subscribes, they will be granted=20 > permission to subscribe. Thats because, if Bob subscribes, the first=20 > policy statement applies to him, resulting in his subscription being=20 > accepted. If Sally subscribes, the second applies to her, and her=20 > subscription is accepted. >=20 > If you try and make except clauses carry across permission=20 > statements,=20 > you end up in a place where these statements are no longer additive,=20 > and you are not privacy safe anymore. >=20 > Now, even given these clarifications, the geopriv group is not=20 > planning on specifying an except condition at this time. Though they=20 > consider it useful, its been ruled out of scope for the=20 > initial policy=20 > document. Thus, if we wish to align, we would need to also=20 > rule it out=20 > of scope in the initial version of the specification. >=20 > That does not mean it could never be done; indeed, it would be my=20 > proposal to more or less immediately have a draft defining it, and=20 > progress this just behind the main specs. Ok. /Hisham >=20 > IMHO, it is worth getting alignment to let this feature move forward=20 > in a separate specification, behind the main one. >=20 > Comments and thoughts? >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=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 exim@www1.ietf.org Mon Nov 24 08:47:05 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08052 for ; Mon, 24 Nov 2003 08:47:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOH3B-0002II-Fq for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 08:46:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAODknTh008812 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 08:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOH3B-0002I3-CZ for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 08:46:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07990; Mon, 24 Nov 2003 08:46:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOH34-00054d-00; Mon, 24 Nov 2003 08:46:42 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AOGxZ-0004vi-00; Mon, 24 Nov 2003 08:41:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AOGhX-0001pI-6i; Mon, 24 Nov 2003 08:24:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOGhA-0007PH-TZ; Mon, 24 Nov 2003 08:24:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOG7P-000664-6a for simple@optimus.ietf.org; Mon, 24 Nov 2003 07:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05916 for ; Mon, 24 Nov 2003 07:46:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOG7N-0003k3-00 for simple@ietf.org; Mon, 24 Nov 2003 07:47:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOG7M-0003jz-00 for simple@ietf.org; Mon, 24 Nov 2003 07:47:04 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAOCl2A04390 for ; Mon, 24 Nov 2003 14:47:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 24 Nov 2003 14:47:02 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 24 Nov 2003 14:47:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B105@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOyWQpLMDZBrDr0S/6Ngtrw7sOB7gALzfAw To: , X-OriginalArrivalTime: 24 Nov 2003 12:47:02.0309 (UTC) FILETIME=[0EAE8D50:01C3B289] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:47:01 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 24.November.2003 09:02 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > This issue consumed a lot of discussion during the Minneapolis IETF. >=20 > The current xcap-auth specification adds support for=20 > exceptions within=20 > the applies-to statements. This allows for a way to say that a=20 > statement applies to all the users in a domain or list EXCEPT the=20 > listed set of users. This is useful for specifying things=20 > like "I want=20 > to grant permission to everyone in dynamicsoft.com except for Bob".=20 > Presumably Bob is an annoying guy and I just don't want to grant him=20 > permission. >=20 > Now, a few points need to be made clear about the exceptions=20 > processing. >=20 > Firstly, having things like this: >=20 > > > > sip:joe@example.com > > >=20 > is completely useless. The reason is that it is really easy to obtain=20 > new names from many namespace providers. As a result, you may thikn=20 > you are blocking Joe, but he just goes off, gets a new URI=20 > from yahoo,=20 > and your permission statement is useless. >=20 > Indeed, the entire notion of except clauses is only useful if you=20 > assume that there are cases where it is hard to obtain new=20 > identifiers. There was some dispute about whether this is a good=20 > assumnption or not. I, and some others, do believe that in many=20 > enterprises, it is a good assumption that obtaining a new enterprise=20 > identifier is not easy. >=20 > A second point on exceptions. If an exception represents a list, and=20 > you can't dereference that list, then you have to drop the entire=20 > permission statement. This is to ensure privacy-safety, so that=20 > information is not leaked under any failure condition. >=20 > Finally, it needs to be clarified that exceptions still result in=20 > additive permissions. So, for example, if I have two=20 > staements like this: >=20 > > example.com > > sip:sally@example.com > > >=20 > >=20 > and >=20 > > example.com > > sip:bob@example.com > > >=20 > >=20 I don't see why someone would compose 2 permissions for the same domain. = What is a scenario for this? >=20 >=20 > That if EITHER Sally or Bob subscribes, they will be granted=20 > permission to subscribe. Thats because, if Bob subscribes, the first=20 > policy statement applies to him, resulting in his subscription being=20 > accepted. If Sally subscribes, the second applies to her, and her=20 > subscription is accepted. >=20 > If you try and make except clauses carry across permission=20 > statements,=20 > you end up in a place where these statements are no longer additive,=20 > and you are not privacy safe anymore. >=20 > Now, even given these clarifications, the geopriv group is not=20 > planning on specifying an except condition at this time. Though they=20 > consider it useful, its been ruled out of scope for the=20 > initial policy=20 > document. Thus, if we wish to align, we would need to also=20 > rule it out=20 > of scope in the initial version of the specification. >=20 > That does not mean it could never be done; indeed, it would be my=20 > proposal to more or less immediately have a draft defining it, and=20 > progress this just behind the main specs. Ok. /Hisham >=20 > IMHO, it is worth getting alignment to let this feature move forward=20 > in a separate specification, behind the main one. >=20 > Comments and thoughts? >=20 > Thanks, > Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=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-admin@ietf.org Mon Nov 24 12:43:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18467; Mon, 24 Nov 2003 12:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKkp-0001Db-00; Mon, 24 Nov 2003 12:44:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKkp-0001DY-00; Mon, 24 Nov 2003 12:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKkj-0003ik-9t; Mon, 24 Nov 2003 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKk4-0003iU-QC for simple@optimus.ietf.org; Mon, 24 Nov 2003 12:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18425 for ; Mon, 24 Nov 2003 12:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKk2-0001Cv-00 for simple@ietf.org; Mon, 24 Nov 2003 12:43:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOKk2-0001Ca-00 for simple@ietf.org; Mon, 24 Nov 2003 12:43:18 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Nov 2003 09:43:57 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOHgkAt008159; Mon, 24 Nov 2003 09:42:46 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKF19540; Mon, 24 Nov 2003 09:42:45 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) From: Cullen Jennings To: Dean Willis , Message-ID: In-Reply-To: <002001c3b07f$140eb830$e1036e3f@txdwillis> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 09:42:45 -0800 Content-Transfer-Encoding: 7bit I went and did some testing with a handful of different NATs and poked around on documentation for more. Here's the initial results I found - if folks can point me to stuff that contradicts this, I would be grateful .... Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 seconds). Due to the multiples retires and such it takes several minutes after this before anything is really killed. The NAT and FW I looked at (mostly Cisco and Linksys but few others too) seem to also set the TCP timeouts at 2 hours plus a bit. This is probably not a coincidence. It is a little disturbing that they are close to the same instead NAT/FW being significantly above the OS default but I'm still trying to understand that. The two hours makes in not much fun to run tests on this stuff :-) Cullen PS - my example of SSH was lousy because many SSH clients allow you to set up application level keep alives. On 11/21/03 2:30 PM, "Dean Willis" wrote: >> >> There was some assertion in the WG meeting that NATs >> arbitrarily kill TCP connection and the connection needs to >> be set up again. I'm sure this has happened with broken NATS >> but I do not feel it is widespread and don't think we should >> specifically design for it. I do think we should design for >> graceful failure or recover when things in the network fail >> but I don't think there is a common case of TCP failing that >> involves NATs. If there were, many things that do not >> automatically set up a new TCP connection, like ssh for >> example, would be nearly unusable through these broken NATs. > > Usually when I'm sittig in a 3GPP2 meeting trying to do email and what not > over an SSH tunnel I run a script on the server-side of the ssh tunnel that > prints a "." every ten seconds. > > Why do I do this? > > Because if I don't, the freaking NAT box (usually a Cisco/Linksys product, > set to defaults I believe) drops my port binding between mail polls, and I > have to restart the ssh connection. The TCP keepalives aren't enough > frequent enough to keep the NAT alive. And restarting ssh si a manual > process, requiring re-entry of a key's secret. > > Translation: ssh IS nearly unusable with these broken NATs, unless one is > keeping it almost constantly busy. MSRP sessions would have very similar > properties. > > I believe this is demonstrably provable whenever the NAT reclamation timer > is shorter than the longest-case interpacket timer, which is generally TCP > keepalives at about ten minutes . . . And considering that most > off-the-shelf NAT/routers seem to run reclamation timers of between thirty > seconds and three minutes, it's a problem. > > -- > Dean > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 12:44:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18502 for ; Mon, 24 Nov 2003 12:44:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKkr-0003jo-OE for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 12:44:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOHi9ac014364 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 12:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKkr-0003jb-L6 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 12:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18467; Mon, 24 Nov 2003 12:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKkp-0001Db-00; Mon, 24 Nov 2003 12:44:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOKkp-0001DY-00; Mon, 24 Nov 2003 12:44:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKkj-0003ik-9t; Mon, 24 Nov 2003 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOKk4-0003iU-QC for simple@optimus.ietf.org; Mon, 24 Nov 2003 12:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18425 for ; Mon, 24 Nov 2003 12:43:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOKk2-0001Cv-00 for simple@ietf.org; Mon, 24 Nov 2003 12:43:19 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOKk2-0001Ca-00 for simple@ietf.org; Mon, 24 Nov 2003 12:43:18 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 24 Nov 2003 09:43:57 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAOHgkAt008159; Mon, 24 Nov 2003 09:42:46 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKF19540; Mon, 24 Nov 2003 09:42:45 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) From: Cullen Jennings To: Dean Willis , Message-ID: In-Reply-To: <002001c3b07f$140eb830$e1036e3f@txdwillis> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 09:42:45 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I went and did some testing with a handful of different NATs and poked around on documentation for more. Here's the initial results I found - if folks can point me to stuff that contradicts this, I would be grateful .... Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 seconds). Due to the multiples retires and such it takes several minutes after this before anything is really killed. The NAT and FW I looked at (mostly Cisco and Linksys but few others too) seem to also set the TCP timeouts at 2 hours plus a bit. This is probably not a coincidence. It is a little disturbing that they are close to the same instead NAT/FW being significantly above the OS default but I'm still trying to understand that. The two hours makes in not much fun to run tests on this stuff :-) Cullen PS - my example of SSH was lousy because many SSH clients allow you to set up application level keep alives. On 11/21/03 2:30 PM, "Dean Willis" wrote: >> >> There was some assertion in the WG meeting that NATs >> arbitrarily kill TCP connection and the connection needs to >> be set up again. I'm sure this has happened with broken NATS >> but I do not feel it is widespread and don't think we should >> specifically design for it. I do think we should design for >> graceful failure or recover when things in the network fail >> but I don't think there is a common case of TCP failing that >> involves NATs. If there were, many things that do not >> automatically set up a new TCP connection, like ssh for >> example, would be nearly unusable through these broken NATs. > > Usually when I'm sittig in a 3GPP2 meeting trying to do email and what not > over an SSH tunnel I run a script on the server-side of the ssh tunnel that > prints a "." every ten seconds. > > Why do I do this? > > Because if I don't, the freaking NAT box (usually a Cisco/Linksys product, > set to defaults I believe) drops my port binding between mail polls, and I > have to restart the ssh connection. The TCP keepalives aren't enough > frequent enough to keep the NAT alive. And restarting ssh si a manual > process, requiring re-entry of a key's secret. > > Translation: ssh IS nearly unusable with these broken NATs, unless one is > keeping it almost constantly busy. MSRP sessions would have very similar > properties. > > I believe this is demonstrably provable whenever the NAT reclamation timer > is shorter than the longest-case interpacket timer, which is generally TCP > keepalives at about ten minutes . . . And considering that most > off-the-shelf NAT/routers seem to run reclamation timers of between thirty > seconds and three minutes, it's a problem. > > -- > Dean > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 13:48:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20924; Mon, 24 Nov 2003 13:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLlg-0002B4-00; Mon, 24 Nov 2003 13:49:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLlf-0002B1-00; Mon, 24 Nov 2003 13:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLld-0007p5-Im; Mon, 24 Nov 2003 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLlX-0007oP-2A for simple@optimus.ietf.org; Mon, 24 Nov 2003 13:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20897 for ; Mon, 24 Nov 2003 13:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLlU-0002Ah-00 for simple@ietf.org; Mon, 24 Nov 2003 13:48:52 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOLlT-0002AJ-00 for simple@ietf.org; Mon, 24 Nov 2003 13:48:52 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAOImVI2010184; Mon, 24 Nov 2003 19:48:32 +0100 (MET) Received: from ericsson.com (sealwp02-168.sw.ericsson.se [153.88.142.168]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XRC3LL5G; Mon, 24 Nov 2003 19:48:32 +0100 Message-ID: <3FC25259.1060804@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 20:47:53 +0200 Content-Transfer-Encoding: 7bit Hi: A question about the recent decision to split the MSRP protocol into a relay-less document and a document that details the use of relays. I would like to understand if the idea is to document the BIND primitive in the relay-less document or in the relayful document. Some folks may argue that the BIND primitive is only used in the case there are relays in the path, and as such, it should be documented in the relays document. However, in doing so, we may risk that end points will not implement the BIND primitive ever, and therefore will not support the operation through relays. I am in favour of documenting the BIND primitive in the core MSRP document, in spite that the relay operation will be described in the relays document. Is this something that the working group is thinking? /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 13:49:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20987 for ; Mon, 24 Nov 2003 13:49:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLlj-0007q1-3F for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 13:49:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOIn7WS030123 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 13:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLli-0007pm-WD for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 13:49:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20924; Mon, 24 Nov 2003 13:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLlg-0002B4-00; Mon, 24 Nov 2003 13:49:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLlf-0002B1-00; Mon, 24 Nov 2003 13:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLld-0007p5-Im; Mon, 24 Nov 2003 13:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLlX-0007oP-2A for simple@optimus.ietf.org; Mon, 24 Nov 2003 13:48:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20897 for ; Mon, 24 Nov 2003 13:48:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLlU-0002Ah-00 for simple@ietf.org; Mon, 24 Nov 2003 13:48:52 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOLlT-0002AJ-00 for simple@ietf.org; Mon, 24 Nov 2003 13:48:52 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAOImVI2010184; Mon, 24 Nov 2003 19:48:32 +0100 (MET) Received: from ericsson.com (sealwp02-168.sw.ericsson.se [153.88.142.168]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XRC3LL5G; Mon, 24 Nov 2003 19:48:32 +0100 Message-ID: <3FC25259.1060804@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 20:47:53 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi: A question about the recent decision to split the MSRP protocol into a relay-less document and a document that details the use of relays. I would like to understand if the idea is to document the BIND primitive in the relay-less document or in the relayful document. Some folks may argue that the BIND primitive is only used in the case there are relays in the path, and as such, it should be documented in the relays document. However, in doing so, we may risk that end points will not implement the BIND primitive ever, and therefore will not support the operation through relays. I am in favour of documenting the BIND primitive in the core MSRP document, in spite that the relay operation will be described in the relays document. Is this something that the working group is thinking? /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 13:55:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21284; Mon, 24 Nov 2003 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLsP-0002Hp-00; Mon, 24 Nov 2003 13:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLsP-0002Hm-00; Mon, 24 Nov 2003 13:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLsP-0000Fr-OH; Mon, 24 Nov 2003 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLrY-0000ET-2L for simple@optimus.ietf.org; Mon, 24 Nov 2003 13:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21261 for ; Mon, 24 Nov 2003 13:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLrU-0002HD-00 for simple@ietf.org; Mon, 24 Nov 2003 13:55:04 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOLrT-0002H1-00 for simple@ietf.org; Mon, 24 Nov 2003 13:55:03 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOIsgnG021149; Mon, 24 Nov 2003 12:54:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC253F0.6090905@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG References: <3FC25259.1060804@ericsson.com> In-Reply-To: <3FC25259.1060804@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 12:54:40 -0600 Content-Transfer-Encoding: 7bit My intent was that the BIND primative, or something simular, would be part of the relay specification. For BIND to be useful, an endpoint must be aware that it wants to use a relay, and roughly how it should interact with the relay. It is not clear to me how we could specify those things generically in the base spec if relays are not documented there. It seems like we must treat relays either as an extension to the base spec, or as a lower layer that MSRP can run on. In either case, in order to choose to use a relay, an MSRP endpoint will require knowlege of the relay specification. Miguel A. Garcia wrote: > Hi: > > A question about the recent decision to split the MSRP protocol into a > relay-less document and a document that details the use of relays. > > I would like to understand if the idea is to document the BIND primitive > in the relay-less document or in the relayful document. > > Some folks may argue that the BIND primitive is only used in the case > there are relays in the path, and as such, it should be documented in > the relays document. However, in doing so, we may risk that end points > will not implement the BIND primitive ever, and therefore will not > support the operation through relays. > > I am in favour of documenting the BIND primitive in the core MSRP > document, in spite that the relay operation will be described in the > relays document. > > Is this something that the working group is thinking? > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 13:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21315 for ; Mon, 24 Nov 2003 13:56:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLsT-0000Ib-7K for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 13:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOIu5Ro001143 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 13:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLsT-0000IM-3w for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 13:56:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21284; Mon, 24 Nov 2003 13:55:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLsP-0002Hp-00; Mon, 24 Nov 2003 13:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOLsP-0002Hm-00; Mon, 24 Nov 2003 13:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLsP-0000Fr-OH; Mon, 24 Nov 2003 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOLrY-0000ET-2L for simple@optimus.ietf.org; Mon, 24 Nov 2003 13:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21261 for ; Mon, 24 Nov 2003 13:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOLrU-0002HD-00 for simple@ietf.org; Mon, 24 Nov 2003 13:55:04 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOLrT-0002H1-00 for simple@ietf.org; Mon, 24 Nov 2003 13:55:03 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOIsgnG021149; Mon, 24 Nov 2003 12:54:53 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC253F0.6090905@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG References: <3FC25259.1060804@ericsson.com> In-Reply-To: <3FC25259.1060804@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 12:54:40 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My intent was that the BIND primative, or something simular, would be part of the relay specification. For BIND to be useful, an endpoint must be aware that it wants to use a relay, and roughly how it should interact with the relay. It is not clear to me how we could specify those things generically in the base spec if relays are not documented there. It seems like we must treat relays either as an extension to the base spec, or as a lower layer that MSRP can run on. In either case, in order to choose to use a relay, an MSRP endpoint will require knowlege of the relay specification. Miguel A. Garcia wrote: > Hi: > > A question about the recent decision to split the MSRP protocol into a > relay-less document and a document that details the use of relays. > > I would like to understand if the idea is to document the BIND primitive > in the relay-less document or in the relayful document. > > Some folks may argue that the BIND primitive is only used in the case > there are relays in the path, and as such, it should be documented in > the relays document. However, in doing so, we may risk that end points > will not implement the BIND primitive ever, and therefore will not > support the operation through relays. > > I am in favour of documenting the BIND primitive in the core MSRP > document, in spite that the relay operation will be described in the > relays document. > > Is this something that the working group is thinking? > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 14:59:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24319; Mon, 24 Nov 2003 14:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMsQ-0003MH-00; Mon, 24 Nov 2003 15:00:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMsQ-0003ME-00; Mon, 24 Nov 2003 15:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMsM-0003rq-Du; Mon, 24 Nov 2003 15:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMrP-0003qF-Sa for simple@optimus.ietf.org; Mon, 24 Nov 2003 14:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24286 for ; Mon, 24 Nov 2003 14:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMrM-0003Lb-00 for simple@ietf.org; Mon, 24 Nov 2003 14:59:01 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AOMrM-0003Ku-00 for simple@ietf.org; Mon, 24 Nov 2003 14:59:00 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hAOJwKYb008343; Mon, 24 Nov 2003 13:58:20 -0600 (CST) Received: from ericsson.com (sealwp02-168.sw.ericsson.se [153.88.142.168]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XH3ZBF6Q; Mon, 24 Nov 2003 13:58:13 -0600 Message-ID: <3FC262B4.5040802@ericsson.com> X-Sybari-Trust: d85b885f 6fa56f4d 14f46472 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> In-Reply-To: <3FC253F0.6090905@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 21:57:40 +0200 Content-Transfer-Encoding: 7bit I don't think I really agree. An endpoint that is configured to use a relay needs to know that it has to start the session by getting the MSRP URI from the relay itself, with a BIND primitive. Then it needs to know that the URI it got is the one he populates in the SDP. What is happening at the other side of the relay is of no interest for the endpoint, and I believe this is what should be documented in the MSRP relay document. Or is there something else the endoint must be aware of (for using a relay)? /Miguel Ben Campbell wrote: > My intent was that the BIND primative, or something simular, would be > part of the relay specification. > > For BIND to be useful, an endpoint must be aware that it wants to use a > relay, and roughly how it should interact with the relay. It is not > clear to me how we could specify those things generically in the base > spec if relays are not documented there. It seems like we must treat > relays either as an extension to the base spec, or as a lower layer that > MSRP can run on. In either case, in order to choose to use a relay, an > MSRP endpoint will require knowlege of the relay specification. > > > > Miguel A. Garcia wrote: > >> Hi: >> >> A question about the recent decision to split the MSRP protocol into a >> relay-less document and a document that details the use of relays. >> >> I would like to understand if the idea is to document the BIND >> primitive in the relay-less document or in the relayful document. >> >> Some folks may argue that the BIND primitive is only used in the case >> there are relays in the path, and as such, it should be documented in >> the relays document. However, in doing so, we may risk that end points >> will not implement the BIND primitive ever, and therefore will not >> support the operation through relays. >> >> I am in favour of documenting the BIND primitive in the core MSRP >> document, in spite that the relay operation will be described in the >> relays document. >> >> Is this something that the working group is thinking? >> >> /Miguel > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:00:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24361 for ; Mon, 24 Nov 2003 15:00:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMsU-0003t5-Ic for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:00:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOK0AfK014943 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:00:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMsU-0003sq-9K for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:00:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24319; Mon, 24 Nov 2003 14:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMsQ-0003MH-00; Mon, 24 Nov 2003 15:00:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMsQ-0003ME-00; Mon, 24 Nov 2003 15:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMsM-0003rq-Du; Mon, 24 Nov 2003 15:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMrP-0003qF-Sa for simple@optimus.ietf.org; Mon, 24 Nov 2003 14:59:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24286 for ; Mon, 24 Nov 2003 14:58:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMrM-0003Lb-00 for simple@ietf.org; Mon, 24 Nov 2003 14:59:01 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AOMrM-0003Ku-00 for simple@ietf.org; Mon, 24 Nov 2003 14:59:00 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hAOJwKYb008343; Mon, 24 Nov 2003 13:58:20 -0600 (CST) Received: from ericsson.com (sealwp02-168.sw.ericsson.se [153.88.142.168]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XH3ZBF6Q; Mon, 24 Nov 2003 13:58:13 -0600 Message-ID: <3FC262B4.5040802@ericsson.com> X-Sybari-Trust: d85b885f 6fa56f4d 14f46472 00000138 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> In-Reply-To: <3FC253F0.6090905@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 21:57:40 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't think I really agree. An endpoint that is configured to use a relay needs to know that it has to start the session by getting the MSRP URI from the relay itself, with a BIND primitive. Then it needs to know that the URI it got is the one he populates in the SDP. What is happening at the other side of the relay is of no interest for the endpoint, and I believe this is what should be documented in the MSRP relay document. Or is there something else the endoint must be aware of (for using a relay)? /Miguel Ben Campbell wrote: > My intent was that the BIND primative, or something simular, would be > part of the relay specification. > > For BIND to be useful, an endpoint must be aware that it wants to use a > relay, and roughly how it should interact with the relay. It is not > clear to me how we could specify those things generically in the base > spec if relays are not documented there. It seems like we must treat > relays either as an extension to the base spec, or as a lower layer that > MSRP can run on. In either case, in order to choose to use a relay, an > MSRP endpoint will require knowlege of the relay specification. > > > > Miguel A. Garcia wrote: > >> Hi: >> >> A question about the recent decision to split the MSRP protocol into a >> relay-less document and a document that details the use of relays. >> >> I would like to understand if the idea is to document the BIND >> primitive in the relay-less document or in the relayful document. >> >> Some folks may argue that the BIND primitive is only used in the case >> there are relays in the path, and as such, it should be documented in >> the relays document. However, in doing so, we may risk that end points >> will not implement the BIND primitive ever, and therefore will not >> support the operation through relays. >> >> I am in favour of documenting the BIND primitive in the core MSRP >> document, in spite that the relay operation will be described in the >> relays document. >> >> Is this something that the working group is thinking? >> >> /Miguel > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 15:04:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24719; Mon, 24 Nov 2003 15:04:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMxB-0003SD-00; Mon, 24 Nov 2003 15:05:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMxB-0003SA-00; Mon, 24 Nov 2003 15:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMxB-0004Q8-6A; Mon, 24 Nov 2003 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMwL-0004KN-82 for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24593 for ; Mon, 24 Nov 2003 15:03:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMwI-0003Qp-00 for simple@ietf.org; Mon, 24 Nov 2003 15:04:06 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOMwH-0003Qi-00 for simple@ietf.org; Mon, 24 Nov 2003 15:04:05 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOK3tnG027373; Mon, 24 Nov 2003 14:03:55 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26428.8040702@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> <3FC262B4.5040802@ericsson.com> In-Reply-To: <3FC262B4.5040802@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:03:52 -0600 Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > I don't think I really agree. An endpoint that is configured to use a > relay needs to know that it has to start the session by getting the MSRP > URI from the relay itself, with a BIND primitive. Then it needs to know > that the URI it got is the one he populates in the SDP. That is exactly the knowledge I was talking about. Additionally, it has to know that relays are even possible to start out with, which implies knowledge of the relay specification. My understanding of the mandate to remove relays from the base spec is that an endpoint that implements the base spec, and not the relay extension, does not know that relays even exist. Furthermore, until we complete the relay specification, we cannot know exactly how BIND should work. I don't think we can put a constraint on the relay specification that prevents it from changing the way you request a relay. What is > happening at the other side of the relay is of no interest for the > endpoint, and I believe this is what should be documented in the MSRP > relay document. > > Or is there something else the endoint must be aware of (for using a > relay)? > > /Miguel > > Ben Campbell wrote: > >> My intent was that the BIND primative, or something simular, would be >> part of the relay specification. >> >> For BIND to be useful, an endpoint must be aware that it wants to use >> a relay, and roughly how it should interact with the relay. It is not >> clear to me how we could specify those things generically in the base >> spec if relays are not documented there. It seems like we must treat >> relays either as an extension to the base spec, or as a lower layer >> that MSRP can run on. In either case, in order to choose to use a >> relay, an MSRP endpoint will require knowlege of the relay specification. >> >> >> >> Miguel A. Garcia wrote: >> >>> Hi: >>> >>> A question about the recent decision to split the MSRP protocol into >>> a relay-less document and a document that details the use of relays. >>> >>> I would like to understand if the idea is to document the BIND >>> primitive in the relay-less document or in the relayful document. >>> >>> Some folks may argue that the BIND primitive is only used in the case >>> there are relays in the path, and as such, it should be documented in >>> the relays document. However, in doing so, we may risk that end >>> points will not implement the BIND primitive ever, and therefore will >>> not support the operation through relays. >>> >>> I am in favour of documenting the BIND primitive in the core MSRP >>> document, in spite that the relay operation will be described in the >>> relays document. >>> >>> Is this something that the working group is thinking? >>> >>> /Miguel >> >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:05:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24813 for ; Mon, 24 Nov 2003 15:05:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMxF-0004Rr-AE for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:05:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOK550q017093 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMxF-0004Rc-6G for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:05:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24719; Mon, 24 Nov 2003 15:04:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMxB-0003SD-00; Mon, 24 Nov 2003 15:05:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOMxB-0003SA-00; Mon, 24 Nov 2003 15:05:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMxB-0004Q8-6A; Mon, 24 Nov 2003 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOMwL-0004KN-82 for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:04:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24593 for ; Mon, 24 Nov 2003 15:03:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOMwI-0003Qp-00 for simple@ietf.org; Mon, 24 Nov 2003 15:04:06 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOMwH-0003Qi-00 for simple@ietf.org; Mon, 24 Nov 2003 15:04:05 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOK3tnG027373; Mon, 24 Nov 2003 14:03:55 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26428.8040702@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> <3FC262B4.5040802@ericsson.com> In-Reply-To: <3FC262B4.5040802@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:03:52 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > I don't think I really agree. An endpoint that is configured to use a > relay needs to know that it has to start the session by getting the MSRP > URI from the relay itself, with a BIND primitive. Then it needs to know > that the URI it got is the one he populates in the SDP. That is exactly the knowledge I was talking about. Additionally, it has to know that relays are even possible to start out with, which implies knowledge of the relay specification. My understanding of the mandate to remove relays from the base spec is that an endpoint that implements the base spec, and not the relay extension, does not know that relays even exist. Furthermore, until we complete the relay specification, we cannot know exactly how BIND should work. I don't think we can put a constraint on the relay specification that prevents it from changing the way you request a relay. What is > happening at the other side of the relay is of no interest for the > endpoint, and I believe this is what should be documented in the MSRP > relay document. > > Or is there something else the endoint must be aware of (for using a > relay)? > > /Miguel > > Ben Campbell wrote: > >> My intent was that the BIND primative, or something simular, would be >> part of the relay specification. >> >> For BIND to be useful, an endpoint must be aware that it wants to use >> a relay, and roughly how it should interact with the relay. It is not >> clear to me how we could specify those things generically in the base >> spec if relays are not documented there. It seems like we must treat >> relays either as an extension to the base spec, or as a lower layer >> that MSRP can run on. In either case, in order to choose to use a >> relay, an MSRP endpoint will require knowlege of the relay specification. >> >> >> >> Miguel A. Garcia wrote: >> >>> Hi: >>> >>> A question about the recent decision to split the MSRP protocol into >>> a relay-less document and a document that details the use of relays. >>> >>> I would like to understand if the idea is to document the BIND >>> primitive in the relay-less document or in the relayful document. >>> >>> Some folks may argue that the BIND primitive is only used in the case >>> there are relays in the path, and as such, it should be documented in >>> the relays document. However, in doing so, we may risk that end >>> points will not implement the BIND primitive ever, and therefore will >>> not support the operation through relays. >>> >>> I am in favour of documenting the BIND primitive in the core MSRP >>> document, in spite that the relay operation will be described in the >>> relays document. >>> >>> Is this something that the working group is thinking? >>> >>> /Miguel >> >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 15:37:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28106; Mon, 24 Nov 2003 15:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONTD-0004Ap-00; Mon, 24 Nov 2003 15:38:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONTC-0004Am-00; Mon, 24 Nov 2003 15:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONT8-0007WZ-0e; Mon, 24 Nov 2003 15:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONT0-0007UY-Nn for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:37:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28100 for ; Mon, 24 Nov 2003 15:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONSz-0004AX-00 for simple@ietf.org; Mon, 24 Nov 2003 15:37:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONSy-0004AT-00 for simple@ietf.org; Mon, 24 Nov 2003 15:37:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKbnnG030137; Mon, 24 Nov 2003 14:37:49 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26C1A.8010408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <3FC1ACEF.2060703@dynamicsoft.com> In-Reply-To: <3FC1ACEF.2060703@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:37:46 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > This issue consumed a lot of discussion during the Minneapolis IETF. > > The current xcap-auth specification adds support for exceptions within > the applies-to statements. This allows for a way to say that a statement > applies to all the users in a domain or list EXCEPT the listed set of > users. This is useful for specifying things like "I want to grant > permission to everyone in dynamicsoft.com except for Bob". Presumably > Bob is an annoying guy and I just don't want to grant him permission. > > Now, a few points need to be made clear about the exceptions processing. > > Firstly, having things like this: > > > > > sip:joe@example.com > > > > is completely useless. The reason is that it is really easy to obtain > new names from many namespace providers. As a result, you may thikn you > are blocking Joe, but he just goes off, gets a new URI from yahoo, and > your permission statement is useless. > Indeed, the entire notion of except clauses is only useful if you assume > that there are cases where it is hard to obtain new identifiers. There > was some dispute about whether this is a good assumnption or not. I, and > some others, do believe that in many enterprises, it is a good > assumption that obtaining a new enterprise identifier is not easy. While agree that outside of walled-gardens your example is not very useful, I do think this is very useful when your applies-to is scoped to a domain. This is not limited to enterprise deployments. It may be true that some providers give away identities for free, it is not the case that _all_ providers do this. In fact, I think the whole argument that you don't need exceptions becauses identities are free is bogus. > > A second point on exceptions. If an exception represents a list, and you > can't dereference that list, then you have to drop the entire permission > statement. This is to ensure privacy-safety, so that information is not > leaked under any failure condition. > > Finally, it needs to be clarified that exceptions still result in > additive permissions. So, for example, if I have two staements like this: > > > example.com > > sip:sally@example.com > > > > > > and > > > example.com > > sip:bob@example.com > > > > > > > > That if EITHER Sally or Bob subscribes, they will be granted permission > to subscribe. Thats because, if Bob subscribes, the first policy > statement applies to him, resulting in his subscription being accepted. > If Sally subscribes, the second applies to her, and her subscription is > accepted. > > If you try and make except clauses carry across permission statements, > you end up in a place where these statements are no longer additive, and > you are not privacy safe anymore. > > Now, even given these clarifications, the geopriv group is not planning > on specifying an except condition at this time. Though they consider it > useful, its been ruled out of scope for the initial policy document. > Thus, if we wish to align, we would need to also rule it out of scope in > the initial version of the specification. > > That does not mean it could never be done; indeed, it would be my > proposal to more or less immediately have a draft defining it, and > progress this just behind the main specs. > > IMHO, it is worth getting alignment to let this feature move forward in > a separate specification, behind the main one. > > Comments and thoughts? I personally do not think we can live without exceptions, even for a little while. Since the additive approach does not allow me to explicitly black-list someone and have that override any other permissions, then the only way I could create a rule that allowed everyone from example.com except alice would be to list every single member of example.com explicitly. This is bad enough from a convenience perspective--but in reality it is very unlikely example.com will share its membership roster with me, so I could not do this even if I wanted to. I am willing to live with limiting exceptions expressions to things that never require external resolution. > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:38:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28132 for ; Mon, 24 Nov 2003 15:38:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONTF-0007bm-MP for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:38:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKc9ZX029240 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:38:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONTF-0007bL-70 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:38:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28106; Mon, 24 Nov 2003 15:37:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONTD-0004Ap-00; Mon, 24 Nov 2003 15:38:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONTC-0004Am-00; Mon, 24 Nov 2003 15:38:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONT8-0007WZ-0e; Mon, 24 Nov 2003 15:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONT0-0007UY-Nn for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:37:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28100 for ; Mon, 24 Nov 2003 15:37:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONSz-0004AX-00 for simple@ietf.org; Mon, 24 Nov 2003 15:37:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONSy-0004AT-00 for simple@ietf.org; Mon, 24 Nov 2003 15:37:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKbnnG030137; Mon, 24 Nov 2003 14:37:49 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26C1A.8010408@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <3FC1ACEF.2060703@dynamicsoft.com> In-Reply-To: <3FC1ACEF.2060703@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:37:46 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > This issue consumed a lot of discussion during the Minneapolis IETF. > > The current xcap-auth specification adds support for exceptions within > the applies-to statements. This allows for a way to say that a statement > applies to all the users in a domain or list EXCEPT the listed set of > users. This is useful for specifying things like "I want to grant > permission to everyone in dynamicsoft.com except for Bob". Presumably > Bob is an annoying guy and I just don't want to grant him permission. > > Now, a few points need to be made clear about the exceptions processing. > > Firstly, having things like this: > > > > > sip:joe@example.com > > > > is completely useless. The reason is that it is really easy to obtain > new names from many namespace providers. As a result, you may thikn you > are blocking Joe, but he just goes off, gets a new URI from yahoo, and > your permission statement is useless. > Indeed, the entire notion of except clauses is only useful if you assume > that there are cases where it is hard to obtain new identifiers. There > was some dispute about whether this is a good assumnption or not. I, and > some others, do believe that in many enterprises, it is a good > assumption that obtaining a new enterprise identifier is not easy. While agree that outside of walled-gardens your example is not very useful, I do think this is very useful when your applies-to is scoped to a domain. This is not limited to enterprise deployments. It may be true that some providers give away identities for free, it is not the case that _all_ providers do this. In fact, I think the whole argument that you don't need exceptions becauses identities are free is bogus. > > A second point on exceptions. If an exception represents a list, and you > can't dereference that list, then you have to drop the entire permission > statement. This is to ensure privacy-safety, so that information is not > leaked under any failure condition. > > Finally, it needs to be clarified that exceptions still result in > additive permissions. So, for example, if I have two staements like this: > > > example.com > > sip:sally@example.com > > > > > > and > > > example.com > > sip:bob@example.com > > > > > > > > That if EITHER Sally or Bob subscribes, they will be granted permission > to subscribe. Thats because, if Bob subscribes, the first policy > statement applies to him, resulting in his subscription being accepted. > If Sally subscribes, the second applies to her, and her subscription is > accepted. > > If you try and make except clauses carry across permission statements, > you end up in a place where these statements are no longer additive, and > you are not privacy safe anymore. > > Now, even given these clarifications, the geopriv group is not planning > on specifying an except condition at this time. Though they consider it > useful, its been ruled out of scope for the initial policy document. > Thus, if we wish to align, we would need to also rule it out of scope in > the initial version of the specification. > > That does not mean it could never be done; indeed, it would be my > proposal to more or less immediately have a draft defining it, and > progress this just behind the main specs. > > IMHO, it is worth getting alignment to let this feature move forward in > a separate specification, behind the main one. > > Comments and thoughts? I personally do not think we can live without exceptions, even for a little while. Since the additive approach does not allow me to explicitly black-list someone and have that override any other permissions, then the only way I could create a rule that allowed everyone from example.com except alice would be to list every single member of example.com explicitly. This is bad enough from a convenience perspective--but in reality it is very unlikely example.com will share its membership roster with me, so I could not do this even if I wanted to. I am willing to live with limiting exceptions expressions to things that never require external resolution. > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 15:39:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28312; Mon, 24 Nov 2003 15:39:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONVA-0004De-00; Mon, 24 Nov 2003 15:40:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONVA-0004Db-00; Mon, 24 Nov 2003 15:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONV5-0007y8-3A; Mon, 24 Nov 2003 15:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONUa-0007wt-8L for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:39:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28242 for ; Mon, 24 Nov 2003 15:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONUY-0004CR-00 for simple@ietf.org; Mon, 24 Nov 2003 15:39:30 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONUY-0004CM-00 for simple@ietf.org; Mon, 24 Nov 2003 15:39:30 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKdQnG030282; Mon, 24 Nov 2003 14:39:26 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26C7C.5030007@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 7: actions and transformations References: <3FC1A9D7.2010105@dynamicsoft.com> In-Reply-To: <3FC1A9D7.2010105@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:39:24 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current xcap-auth document, the spec describes two different > types of permissions. These are "acceptance" permissions and "content" > permissions. The former are permissions about who can or cannot > subscribe in the first place. The latter are permissions about what they > will see when they do subscribe. > > In geopriv, they instead have "actions" and "transformations". The > actions are things to do - accept a subscription, confirm a > subscription. Other possible actions in the future might be to log the > event, send an IM, etc. Then "transformations" specify operations on the > data that the watcher will receive. This is equivalent to what we call > content permissions. > > The geopriv document separates these types of elements within the > document through an enclosing "actions" and "transformations" tag. In > xcap-auth, its flat, and no syntactic distinction is made between the > two types. > > I would propose we adopt the geopriv terminology and xml syntax. Using > the syntax has the benefit that, with the xcap protocol, you could > change all of the actions or all of the transformations in one > operation. The terminology is apparently more consistent with other > policy languages that exist. > > As an example of what this change would mean, here is a document in the > current xcap-auth format: > > > sip:joe@example.com > > > > rpid > > > and with this change, would look like: > > > sip:joe@example.com > > > > > > > > rpid > This sounds reasonable to me. It seems to future-proof things a little better than the original xcap-auth syntax. > > > Thanks, > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:40:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28385 for ; Mon, 24 Nov 2003 15:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONVE-00082Y-AS for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:40:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKeCAU030899 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:40:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONVE-00082H-5Y for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:40:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28312; Mon, 24 Nov 2003 15:39:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONVA-0004De-00; Mon, 24 Nov 2003 15:40:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONVA-0004Db-00; Mon, 24 Nov 2003 15:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONV5-0007y8-3A; Mon, 24 Nov 2003 15:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONUa-0007wt-8L for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:39:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28242 for ; Mon, 24 Nov 2003 15:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONUY-0004CR-00 for simple@ietf.org; Mon, 24 Nov 2003 15:39:30 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONUY-0004CM-00 for simple@ietf.org; Mon, 24 Nov 2003 15:39:30 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKdQnG030282; Mon, 24 Nov 2003 14:39:26 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26C7C.5030007@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 7: actions and transformations References: <3FC1A9D7.2010105@dynamicsoft.com> In-Reply-To: <3FC1A9D7.2010105@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:39:24 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current xcap-auth document, the spec describes two different > types of permissions. These are "acceptance" permissions and "content" > permissions. The former are permissions about who can or cannot > subscribe in the first place. The latter are permissions about what they > will see when they do subscribe. > > In geopriv, they instead have "actions" and "transformations". The > actions are things to do - accept a subscription, confirm a > subscription. Other possible actions in the future might be to log the > event, send an IM, etc. Then "transformations" specify operations on the > data that the watcher will receive. This is equivalent to what we call > content permissions. > > The geopriv document separates these types of elements within the > document through an enclosing "actions" and "transformations" tag. In > xcap-auth, its flat, and no syntactic distinction is made between the > two types. > > I would propose we adopt the geopriv terminology and xml syntax. Using > the syntax has the benefit that, with the xcap protocol, you could > change all of the actions or all of the transformations in one > operation. The terminology is apparently more consistent with other > policy languages that exist. > > As an example of what this change would mean, here is a document in the > current xcap-auth format: > > > sip:joe@example.com > > > > rpid > > > and with this change, would look like: > > > sip:joe@example.com > > > > > > > > rpid > This sounds reasonable to me. It seems to future-proof things a little better than the original xcap-auth syntax. > > > Thanks, > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 15:47:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28792; Mon, 24 Nov 2003 15:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONct-0004NH-00; Mon, 24 Nov 2003 15:48:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONct-0004NE-00; Mon, 24 Nov 2003 15:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONco-00005O-NW; Mon, 24 Nov 2003 15:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONcm-000052-7a for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:48:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28789 for ; Mon, 24 Nov 2003 15:47:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONcj-0004N5-00 for simple@ietf.org; Mon, 24 Nov 2003 15:47:57 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONci-0004N0-00 for simple@ietf.org; Mon, 24 Nov 2003 15:47:56 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKljnG030994; Mon, 24 Nov 2003 14:47:52 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26E6F.9030908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation References: <3FC1A843.9020109@dynamicsoft.com> In-Reply-To: <3FC1A843.9020109@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:47:43 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current xcap-auth model, there is an important assumption that if > there are no statements that apply to a watcher, the implication is that > their subscription is pending, and that the presentity should get a > winfo notification about the fact that its pending, so that they can > make a policy decision. This assumption is based on another assumption I > made, which is that the ONLY reason that a watcher would go into the > pending state, is if you have not specified a policy for them yet. > > However, geopriv doesnt make this assumption. They have an element > called "confirm-subscription". If present, it means that the presentity > should be alerted about the subscription, and asked for confirmation. As > a result, there is a way to EXPLICITLY say "let me know if this person > subscribes". > > I think there are legitimate use cases for this, which came up during > the geopriv meeting in Minneapolis. In particular, I may grant my boss > permission to subscribe during the day, but during the evening, I want > to be prompted each time, to see if I will grant it or not. > > To do this, we could follow their lead and add a "confirm-subscription" > boolean, which would explicitly place the watcher into the pending state. > > I think this makes sense, and I would suggest adding this capability to > xcap-auth. I think I like this. So if we were to do this, would that mean the default for when no rules apply would become "deny"? This does, however, bring up a concern that I tried to express in Minneapolis, but am not sure I ever managed to make my point. Most existing presence systems have a concept of blocking an identity. The additive permissions approach seems to make this difficult to implement. If I, for example, want to block alice@example.com, I must make sure that no other rule can possibly include alice. This is further complicated if some of my rules apply to external lists. Even if Alice is not on such a list today, someone might put her on one tomorrow, and invalidate my block. The easiest way to make sure this never happens would be to add an except clause for Alice to _every_ rule I have. That seems pretty cumbersome and error prone. And yes, I understand the arguments in geopriv about black-lists being useless. I just don't think I could sell those arguments to a customer. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:48:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28836 for ; Mon, 24 Nov 2003 15:48:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONcw-00007O-1t for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKm9Rc000448 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONcv-000079-Qc for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:48:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28792; Mon, 24 Nov 2003 15:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONct-0004NH-00; Mon, 24 Nov 2003 15:48:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONct-0004NE-00; Mon, 24 Nov 2003 15:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONco-00005O-NW; Mon, 24 Nov 2003 15:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONcm-000052-7a for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:48:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28789 for ; Mon, 24 Nov 2003 15:47:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONcj-0004N5-00 for simple@ietf.org; Mon, 24 Nov 2003 15:47:57 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONci-0004N0-00 for simple@ietf.org; Mon, 24 Nov 2003 15:47:56 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKljnG030994; Mon, 24 Nov 2003 14:47:52 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26E6F.9030908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation References: <3FC1A843.9020109@dynamicsoft.com> In-Reply-To: <3FC1A843.9020109@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:47:43 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current xcap-auth model, there is an important assumption that if > there are no statements that apply to a watcher, the implication is that > their subscription is pending, and that the presentity should get a > winfo notification about the fact that its pending, so that they can > make a policy decision. This assumption is based on another assumption I > made, which is that the ONLY reason that a watcher would go into the > pending state, is if you have not specified a policy for them yet. > > However, geopriv doesnt make this assumption. They have an element > called "confirm-subscription". If present, it means that the presentity > should be alerted about the subscription, and asked for confirmation. As > a result, there is a way to EXPLICITLY say "let me know if this person > subscribes". > > I think there are legitimate use cases for this, which came up during > the geopriv meeting in Minneapolis. In particular, I may grant my boss > permission to subscribe during the day, but during the evening, I want > to be prompted each time, to see if I will grant it or not. > > To do this, we could follow their lead and add a "confirm-subscription" > boolean, which would explicitly place the watcher into the pending state. > > I think this makes sense, and I would suggest adding this capability to > xcap-auth. I think I like this. So if we were to do this, would that mean the default for when no rules apply would become "deny"? This does, however, bring up a concern that I tried to express in Minneapolis, but am not sure I ever managed to make my point. Most existing presence systems have a concept of blocking an identity. The additive permissions approach seems to make this difficult to implement. If I, for example, want to block alice@example.com, I must make sure that no other rule can possibly include alice. This is further complicated if some of my rules apply to external lists. Even if Alice is not on such a list today, someone might put her on one tomorrow, and invalidate my block. The easiest way to make sure this never happens would be to add an except clause for Alice to _every_ rule I have. That seems pretty cumbersome and error prone. And yes, I understand the arguments in geopriv about black-lists being useless. I just don't think I could sell those arguments to a customer. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 15:53:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29091; Mon, 24 Nov 2003 15:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONie-0004TM-00; Mon, 24 Nov 2003 15:54:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONid-0004TJ-00; Mon, 24 Nov 2003 15:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONib-0000aX-Qy; Mon, 24 Nov 2003 15:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONht-0000ZE-Az for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29040 for ; Mon, 24 Nov 2003 15:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONhr-0004SP-00 for simple@ietf.org; Mon, 24 Nov 2003 15:53:15 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONhq-0004SM-00 for simple@ietf.org; Mon, 24 Nov 2003 15:53:14 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKrCnG031471; Mon, 24 Nov 2003 14:53:12 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26FB5.4090105@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data types References: <3FC1A615.1010506@dynamicsoft.com> In-Reply-To: <3FC1A615.1010506@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:53:09 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current xcap-auth spec, there is a big assumption that each > permission (show-element, show-namespace, accept, accept-if, etc.) is > basically a token datatype. If multiple statements apply, the overall > permissions are the union across these tokens. > > However, in the geopriv spec, they define some additional data types. > Namely, they define boolean and integer. Combining operations are then > also defined for these types (logical OR for booleans, MAX operator for > integers). > > As an example, lets say you have a permission called "accuracy": > > > sip:fluffy@cisco.com > > > 10 > > > > > cisco.com > > > 5 > > > This would have the effect of granting an accuracy of 5 to everyone in > Cisco, excepting fluffy who would get 10. > > The question, then, is whether or not to define/allow these data types > and also define their combining rules. NOTE WELL - you would need to > properly define your permissions such that, for an integer, a larger > value is always more permissive. For booleans, TRUE would need to always > be more permissive. I am having trouble understanding how this is any different than previously proposed, at least in the case of your example. Previously, this simply meant 2 rules matched fluffy--so if 10 is more permissive than 5, he effectively has 10. Would this proposal allow a combination rule that would give fluffy 15? > > A related issue is whether or not to convert some of our current > permissions from tokens to booleans. In particular, the accept, > all-content and show-note permissions would become booleans. The benefit > of that is that you can explicitly say no by setting a value to false: > > > sip:schulzrinne@columbia.edu > > > false > > > would explicitly reject any subscriptions from Henning. Hmm. I assume that if another matching rule sayd true then true would win, right? Otherwise, we no longer have additive permissions. > > So, the question is whether or not to (1) add support for integral and > boolean data types, and (2) convert the all-content, show-note and > accept permissions to booleans. I believe that, independent of geopriv > alignment, these are both good ideas and we should do it. > > Comments? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:54:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29127 for ; Mon, 24 Nov 2003 15:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONih-0000d0-9v for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:54:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKs7Oe002407 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:54:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONih-0000ck-5f for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:54:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29091; Mon, 24 Nov 2003 15:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONie-0004TM-00; Mon, 24 Nov 2003 15:54:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONid-0004TJ-00; Mon, 24 Nov 2003 15:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONib-0000aX-Qy; Mon, 24 Nov 2003 15:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONht-0000ZE-Az for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:53:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29040 for ; Mon, 24 Nov 2003 15:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONhr-0004SP-00 for simple@ietf.org; Mon, 24 Nov 2003 15:53:15 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONhq-0004SM-00 for simple@ietf.org; Mon, 24 Nov 2003 15:53:14 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKrCnG031471; Mon, 24 Nov 2003 14:53:12 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC26FB5.4090105@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data types References: <3FC1A615.1010506@dynamicsoft.com> In-Reply-To: <3FC1A615.1010506@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:53:09 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current xcap-auth spec, there is a big assumption that each > permission (show-element, show-namespace, accept, accept-if, etc.) is > basically a token datatype. If multiple statements apply, the overall > permissions are the union across these tokens. > > However, in the geopriv spec, they define some additional data types. > Namely, they define boolean and integer. Combining operations are then > also defined for these types (logical OR for booleans, MAX operator for > integers). > > As an example, lets say you have a permission called "accuracy": > > > sip:fluffy@cisco.com > > > 10 > > > > > cisco.com > > > 5 > > > This would have the effect of granting an accuracy of 5 to everyone in > Cisco, excepting fluffy who would get 10. > > The question, then, is whether or not to define/allow these data types > and also define their combining rules. NOTE WELL - you would need to > properly define your permissions such that, for an integer, a larger > value is always more permissive. For booleans, TRUE would need to always > be more permissive. I am having trouble understanding how this is any different than previously proposed, at least in the case of your example. Previously, this simply meant 2 rules matched fluffy--so if 10 is more permissive than 5, he effectively has 10. Would this proposal allow a combination rule that would give fluffy 15? > > A related issue is whether or not to convert some of our current > permissions from tokens to booleans. In particular, the accept, > all-content and show-note permissions would become booleans. The benefit > of that is that you can explicitly say no by setting a value to false: > > > sip:schulzrinne@columbia.edu > > > false > > > would explicitly reject any subscriptions from Henning. Hmm. I assume that if another matching rule sayd true then true would win, right? Otherwise, we no longer have additive permissions. > > So, the question is whether or not to (1) add support for integral and > boolean data types, and (2) convert the all-content, show-note and > accept permissions to booleans. I believe that, independent of geopriv > alignment, these are both good ideas and we should do it. > > Comments? > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 15:58:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29260; Mon, 24 Nov 2003 15:58:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONmw-0004Wc-00; Mon, 24 Nov 2003 15:58:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONmw-0004W3-00; Mon, 24 Nov 2003 15:58:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONmU-0000oJ-1n; Mon, 24 Nov 2003 15:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONmD-0000mb-JE for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:57:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29228 for ; Mon, 24 Nov 2003 15:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONmB-0004Vw-00 for simple@ietf.org; Mon, 24 Nov 2003 15:57:44 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONmA-0004Vt-00 for simple@ietf.org; Mon, 24 Nov 2003 15:57:43 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKvVnG031869; Mon, 24 Nov 2003 14:57:40 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC270B8.7010903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <3FC1A166.60901@dynamicsoft.com> In-Reply-To: <3FC1A166.60901@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:57:28 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > Currently, xcap-auth defines an authentication condition. This allows > you to decide whether to accept or reject a subscription based on the > type of authentication used in the SUBSCRIBE request. > > The geopriv policy specification currently has no such mechanism. > > This was discussed during the geopriv meeting in Minneapolis. If you > think about it for a bit, its not clear how this would actually get > used. Remember, it is end users that will set these policies. What kind > of meaningful information can be provided to a user about the > differences between p-asserted-id and sip-identity and digest > authentication? What would make a user give permission for one type or > authentication, and not another? Practically speaking, it doesnt seem > like its easy to use at all. > > As a result, I would propose to remove the authentication condition from > xcap-auth. > > Comments? I agree. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 15:58:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29298 for ; Mon, 24 Nov 2003 15:58:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONmz-0000uf-KD for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:58:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOKwXwO003503 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 15:58:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONmz-0000uQ-G5 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 15:58:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29260; Mon, 24 Nov 2003 15:58:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONmw-0004Wc-00; Mon, 24 Nov 2003 15:58:31 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONmw-0004W3-00; Mon, 24 Nov 2003 15:58:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONmU-0000oJ-1n; Mon, 24 Nov 2003 15:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONmD-0000mb-JE for simple@optimus.ietf.org; Mon, 24 Nov 2003 15:57:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29228 for ; Mon, 24 Nov 2003 15:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONmB-0004Vw-00 for simple@ietf.org; Mon, 24 Nov 2003 15:57:44 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONmA-0004Vt-00 for simple@ietf.org; Mon, 24 Nov 2003 15:57:43 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOKvVnG031869; Mon, 24 Nov 2003 14:57:40 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC270B8.7010903@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <3FC1A166.60901@dynamicsoft.com> In-Reply-To: <3FC1A166.60901@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 14:57:28 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > Currently, xcap-auth defines an authentication condition. This allows > you to decide whether to accept or reject a subscription based on the > type of authentication used in the SUBSCRIBE request. > > The geopriv policy specification currently has no such mechanism. > > This was discussed during the geopriv meeting in Minneapolis. If you > think about it for a bit, its not clear how this would actually get > used. Remember, it is end users that will set these policies. What kind > of meaningful information can be provided to a user about the > differences between p-asserted-id and sip-identity and digest > authentication? What would make a user give permission for one type or > authentication, and not another? Practically speaking, it doesnt seem > like its easy to use at all. > > As a result, I would propose to remove the authentication condition from > xcap-auth. > > Comments? I agree. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 16:00:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29507; Mon, 24 Nov 2003 16:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONpR-0004ar-00; Mon, 24 Nov 2003 16:01:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONpR-0004ao-00; Mon, 24 Nov 2003 16:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONpO-00019E-6o; Mon, 24 Nov 2003 16:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONp0-00017w-6i for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:00:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29474 for ; Mon, 24 Nov 2003 16:00:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONoy-0004aD-00 for simple@ietf.org; Mon, 24 Nov 2003 16:00:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONox-0004a7-00 for simple@ietf.org; Mon, 24 Nov 2003 16:00:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL0QnG032154; Mon, 24 Nov 2003 15:00:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC27167.2010500@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <2038BCC78B1AD641891A0D1AE133DBB701797428@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797428@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:00:23 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Can the user at least have a say in accepting or rejecting the subscription based on the availability of any authentication type. Eg: A user can reject subscriptions that are not authenticated in any way and accept subscriptions that are authenticated, regardless of authentication type. In the absence of _some_ authentication, what is the value of having authorization policies in the first place? They have no meaning if you cannot put some degree of trust in the requestor identity. I think the email world has proven to us how useful it is to authorize on un-authenticated headers. How useful is a spam filter that relies on the From header? > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 24.November.2003 08:13 >>To: Simple WG >>Subject: [Simple] xcap/geopriv alignment issue 4: authentication >> >> >>Folks, >> >>Currently, xcap-auth defines an authentication condition. This allows >>you to decide whether to accept or reject a subscription based on the >>type of authentication used in the SUBSCRIBE request. >> >>The geopriv policy specification currently has no such mechanism. >> >>This was discussed during the geopriv meeting in Minneapolis. If you >>think about it for a bit, its not clear how this would actually get >>used. Remember, it is end users that will set these policies. What >>kind of meaningful information can be provided to a user about the >>differences between p-asserted-id and sip-identity and digest >>authentication? What would make a user give permission for >>one type or >>authentication, and not another? Practically speaking, it doesnt seem >>like its easy to use at all. >> >>As a result, I would propose to remove the authentication condition >>from xcap-auth. >> >>Comments? >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 16:01:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29550 for ; Mon, 24 Nov 2003 16:01:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONpT-0001AI-M3 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOL17C5004471 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:01:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONpT-0001A2-Hf for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 16:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29507; Mon, 24 Nov 2003 16:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONpR-0004ar-00; Mon, 24 Nov 2003 16:01:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONpR-0004ao-00; Mon, 24 Nov 2003 16:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONpO-00019E-6o; Mon, 24 Nov 2003 16:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONp0-00017w-6i for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:00:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29474 for ; Mon, 24 Nov 2003 16:00:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONoy-0004aD-00 for simple@ietf.org; Mon, 24 Nov 2003 16:00:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONox-0004a7-00 for simple@ietf.org; Mon, 24 Nov 2003 16:00:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL0QnG032154; Mon, 24 Nov 2003 15:00:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC27167.2010500@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <2038BCC78B1AD641891A0D1AE133DBB701797428@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797428@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:00:23 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Can the user at least have a say in accepting or rejecting the subscription based on the availability of any authentication type. Eg: A user can reject subscriptions that are not authenticated in any way and accept subscriptions that are authenticated, regardless of authentication type. In the absence of _some_ authentication, what is the value of having authorization policies in the first place? They have no meaning if you cannot put some degree of trust in the requestor identity. I think the email world has proven to us how useful it is to authorize on un-authenticated headers. How useful is a spam filter that relies on the From header? > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 24.November.2003 08:13 >>To: Simple WG >>Subject: [Simple] xcap/geopriv alignment issue 4: authentication >> >> >>Folks, >> >>Currently, xcap-auth defines an authentication condition. This allows >>you to decide whether to accept or reject a subscription based on the >>type of authentication used in the SUBSCRIBE request. >> >>The geopriv policy specification currently has no such mechanism. >> >>This was discussed during the geopriv meeting in Minneapolis. If you >>think about it for a bit, its not clear how this would actually get >>used. Remember, it is end users that will set these policies. What >>kind of meaningful information can be provided to a user about the >>differences between p-asserted-id and sip-identity and digest >>authentication? What would make a user give permission for >>one type or >>authentication, and not another? Practically speaking, it doesnt seem >>like its easy to use at all. >> >>As a result, I would propose to remove the authentication condition >>from xcap-auth. >> >>Comments? >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 16:02:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29615; Mon, 24 Nov 2003 16:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONrP-0004e0-00; Mon, 24 Nov 2003 16:03:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONrP-0004dx-00; Mon, 24 Nov 2003 16:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrJ-0001Fj-CK; Mon, 24 Nov 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONqs-0001FA-N4 for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:02:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29596 for ; Mon, 24 Nov 2003 16:02:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONqr-0004dZ-00 for simple@ietf.org; Mon, 24 Nov 2003 16:02:33 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONqq-0004dW-00 for simple@ietf.org; Mon, 24 Nov 2003 16:02:32 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL2UnG032338; Mon, 24 Nov 2003 15:02:30 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC271E3.4050109@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 2: validity References: <3FC19F06.3070507@dynamicsoft.com> In-Reply-To: <3FC19F06.3070507@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:02:27 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > The geopriv policy document has a validity condition. This validity > conditions defines a start and stop time wherein the policy statement > applies. There are no repeats; that is, you can't have a statement be > valid from 9am to 5pm every day. > > An example is: > > > example.com > 2003-08-15T10:20:00.000-05:00 > 2003-09-15T10:20:00.000-05:00 > > > > > Of course, an alternative to having this validity condition is that the > client simply remove the statement at the appointed time. This is more > or less what we would have to do today in xcap to support any time > limited policies. > > However, there is a privacy advantage to the geopriv approach. If, for > some reason, the client got disconnected, it would not be able to go an > explicitly remove the document. Thus, information might get leaked > because the user couldnt reconnect to stop it from being leaked. If a > validity condition is included in the statement itself, the client can > be sure their privacy is maintained. > > Another benefit is, for cases where the client does want to set policies > that apply from 9am-5pm each day, the client could reconnect each > morning and simply change the valid-from and valid-until dates, instead > of uploading a whole new document (which is what they would need to do > now in xcap-auth). Also, to be clear, once the document is no longer > valid, the server DOES NOT remove it. It stays, and is simply ignored. > > As such, I would propose to adopt the validity condition element. I > think its valuable, independent of any desire to align with geopriv. > > Comments? I agree. > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 16:03:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29693 for ; Mon, 24 Nov 2003 16:03:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrS-0001KO-4s for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:03:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOL3A4G005098 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrS-0001K9-1F for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 16:03:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29615; Mon, 24 Nov 2003 16:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONrP-0004e0-00; Mon, 24 Nov 2003 16:03:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONrP-0004dx-00; Mon, 24 Nov 2003 16:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONrJ-0001Fj-CK; Mon, 24 Nov 2003 16:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONqs-0001FA-N4 for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:02:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29596 for ; Mon, 24 Nov 2003 16:02:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONqr-0004dZ-00 for simple@ietf.org; Mon, 24 Nov 2003 16:02:33 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONqq-0004dW-00 for simple@ietf.org; Mon, 24 Nov 2003 16:02:32 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL2UnG032338; Mon, 24 Nov 2003 15:02:30 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC271E3.4050109@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 2: validity References: <3FC19F06.3070507@dynamicsoft.com> In-Reply-To: <3FC19F06.3070507@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:02:27 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > The geopriv policy document has a validity condition. This validity > conditions defines a start and stop time wherein the policy statement > applies. There are no repeats; that is, you can't have a statement be > valid from 9am to 5pm every day. > > An example is: > > > example.com > 2003-08-15T10:20:00.000-05:00 > 2003-09-15T10:20:00.000-05:00 > > > > > Of course, an alternative to having this validity condition is that the > client simply remove the statement at the appointed time. This is more > or less what we would have to do today in xcap to support any time > limited policies. > > However, there is a privacy advantage to the geopriv approach. If, for > some reason, the client got disconnected, it would not be able to go an > explicitly remove the document. Thus, information might get leaked > because the user couldnt reconnect to stop it from being leaked. If a > validity condition is included in the statement itself, the client can > be sure their privacy is maintained. > > Another benefit is, for cases where the client does want to set policies > that apply from 9am-5pm each day, the client could reconnect each > morning and simply change the valid-from and valid-until dates, instead > of uploading a whole new document (which is what they would need to do > now in xcap-auth). Also, to be clear, once the document is no longer > valid, the server DOES NOT remove it. It stays, and is simply ignored. > > As such, I would propose to adopt the validity condition element. I > think its valuable, independent of any desire to align with geopriv. > > Comments? I agree. > > Thanks, > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 16:04:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29797; Mon, 24 Nov 2003 16:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONtI-0004fy-00; Mon, 24 Nov 2003 16:05:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONtI-0004fv-00; Mon, 24 Nov 2003 16:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONtH-0001Rz-BN; Mon, 24 Nov 2003 16:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONsW-0001Pz-CG for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:04:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29728 for ; Mon, 24 Nov 2003 16:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONsU-0004f7-00 for simple@ietf.org; Mon, 24 Nov 2003 16:04:14 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONsT-0004f3-00 for simple@ietf.org; Mon, 24 Nov 2003 16:04:13 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL4BnG032386; Mon, 24 Nov 2003 15:04:11 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC27248.90702@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment, issue 1: conditions References: <3FC19D75.3040800@dynamicsoft.com> In-Reply-To: <3FC19D75.3040800@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:04:08 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > This is one of a few mails I will send out regarding differences in the > models and operations between the geopriv policy mechanism (which you > can find at > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-00.txt ) > and xcap-auth. > > In the current xcap-auth spec, the only place where a policy is > conditionally applied is with the accept-if statement. It allows you to > say, for example, that the subscription should be accepted if the > watcher was anonymous: > > > example.com > > > > > > > In xcap-auth, conditional checks are used within the applies-to tag, so > that an entire policy statement can be conditional, rather than just a > piece of it. The benefit of this approach is that, once a condition > (such as "if anonymous") is defined, you can make all kinds of policy > choices based on it, besides accept/reject. FOr example, I can decide to > give out only certain information to anonymous watchers. > > Moving the condition tag into applies-to would look like this: > > > example.com > > > > > > Note that a statement is used if all of the conditions listed match. > That is, its an AND operation, not OR. > > So, the question is, do we follow the geopriv model here, and make > conditions part of the applies-to tag only? I believe we should, as it > gives us more functionality at no cost, independent of any desire for > alignment. > > Comments? > Agreed. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 16:05:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29835 for ; Mon, 24 Nov 2003 16:05:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONtL-0001U4-3s for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:05:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOL57TL005698 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONtL-0001Tp-0Y for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 16:05:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29797; Mon, 24 Nov 2003 16:04:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONtI-0004fy-00; Mon, 24 Nov 2003 16:05:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONtI-0004fv-00; Mon, 24 Nov 2003 16:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONtH-0001Rz-BN; Mon, 24 Nov 2003 16:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONsW-0001Pz-CG for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:04:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29728 for ; Mon, 24 Nov 2003 16:04:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONsU-0004f7-00 for simple@ietf.org; Mon, 24 Nov 2003 16:04:14 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONsT-0004f3-00 for simple@ietf.org; Mon, 24 Nov 2003 16:04:13 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL4BnG032386; Mon, 24 Nov 2003 15:04:11 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC27248.90702@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment, issue 1: conditions References: <3FC19D75.3040800@dynamicsoft.com> In-Reply-To: <3FC19D75.3040800@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:04:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > This is one of a few mails I will send out regarding differences in the > models and operations between the geopriv policy mechanism (which you > can find at > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-00.txt ) > and xcap-auth. > > In the current xcap-auth spec, the only place where a policy is > conditionally applied is with the accept-if statement. It allows you to > say, for example, that the subscription should be accepted if the > watcher was anonymous: > > > example.com > > > > > > > In xcap-auth, conditional checks are used within the applies-to tag, so > that an entire policy statement can be conditional, rather than just a > piece of it. The benefit of this approach is that, once a condition > (such as "if anonymous") is defined, you can make all kinds of policy > choices based on it, besides accept/reject. FOr example, I can decide to > give out only certain information to anonymous watchers. > > Moving the condition tag into applies-to would look like this: > > > example.com > > > > > > Note that a statement is used if all of the conditions listed match. > That is, its an AND operation, not OR. > > So, the question is, do we follow the geopriv model here, and make > conditions part of the applies-to tag only? I believe we should, as it > gives us more functionality at no cost, independent of any desire for > alignment. > > Comments? > Agreed. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 16:06:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29874; Mon, 24 Nov 2003 16:06:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONvC-0004hY-00; Mon, 24 Nov 2003 16:07:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONvB-0004hV-00; Mon, 24 Nov 2003 16:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONvB-0001Ze-Du; Mon, 24 Nov 2003 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONuM-0001Y9-Rh for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:06:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29865 for ; Mon, 24 Nov 2003 16:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONuL-0004hB-00 for simple@ietf.org; Mon, 24 Nov 2003 16:06:09 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONuK-0004h6-00 for simple@ietf.org; Mon, 24 Nov 2003 16:06:08 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL65nG032545; Mon, 24 Nov 2003 15:06:05 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC272BA.9010106@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 3: spheres References: <3FC1A098.6060007@dynamicsoft.com> In-Reply-To: <3FC1A098.6060007@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:06:02 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current geopriv policy document, there is a condition called > "sphere". This allows a presentity to tell the server that this policy > statement only applies if the current sphere of the presentity has some > value. Sphere refers to an RPID element (which, afaik, is not in the > current rpid document, and would need to be added for this to be useful) > that describes my current situation - whether I am at work, at home, > sleeping, etc. Its a dynamic context, for which my privacy rules vary as > the context varies. > > As an example, I could define a policy thusly: > > > example.com > work > > > > > > > and: > > > example.com > home > > > > basic > > > This would have the effect of showing my example.com colleauges my full > presence when I'm at work, but only my basic status when I'm at home. > > So, the question is, do we adopt this in xcap-auth? > > I am inclined to NOT adopt it, and indeed, to encourage geopriv to > remove it, in order to reduce scope. > > Comments? I have mixed emotions on this one, as I have heard a lot of discussion of people wanting to do things that this would enable. At the same time, I am willing to defer it for the future. I can accomplish something similar by simply having a separate identity for home and work--although many existing clients make this inconventient. > > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 16:07:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29900 for ; Mon, 24 Nov 2003 16:07:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONvF-0001el-S5 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:07:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOL755Q006361 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:07:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONvE-0001di-TG for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 16:07:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29874; Mon, 24 Nov 2003 16:06:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONvC-0004hY-00; Mon, 24 Nov 2003 16:07:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AONvB-0004hV-00; Mon, 24 Nov 2003 16:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONvB-0001Ze-Du; Mon, 24 Nov 2003 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AONuM-0001Y9-Rh for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:06:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29865 for ; Mon, 24 Nov 2003 16:05:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AONuL-0004hB-00 for simple@ietf.org; Mon, 24 Nov 2003 16:06:09 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AONuK-0004h6-00 for simple@ietf.org; Mon, 24 Nov 2003 16:06:08 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOL65nG032545; Mon, 24 Nov 2003 15:06:05 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC272BA.9010106@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 3: spheres References: <3FC1A098.6060007@dynamicsoft.com> In-Reply-To: <3FC1A098.6060007@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 15:06:02 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > In the current geopriv policy document, there is a condition called > "sphere". This allows a presentity to tell the server that this policy > statement only applies if the current sphere of the presentity has some > value. Sphere refers to an RPID element (which, afaik, is not in the > current rpid document, and would need to be added for this to be useful) > that describes my current situation - whether I am at work, at home, > sleeping, etc. Its a dynamic context, for which my privacy rules vary as > the context varies. > > As an example, I could define a policy thusly: > > > example.com > work > > > > > > > and: > > > example.com > home > > > > basic > > > This would have the effect of showing my example.com colleauges my full > presence when I'm at work, but only my basic status when I'm at home. > > So, the question is, do we adopt this in xcap-auth? > > I am inclined to NOT adopt it, and indeed, to encourage geopriv to > remove it, in order to reduce scope. > > Comments? I have mixed emotions on this one, as I have heard a lot of discussion of people wanting to do things that this would enable. At the same time, I am willing to defer it for the future. I can accomplish something similar by simply having a separate identity for home and work--although many existing clients make this inconventient. > > Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 16:40:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02634; Mon, 24 Nov 2003 16:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOS3-0005ap-00; Mon, 24 Nov 2003 16:40:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOOS2-0005Zh-00; Mon, 24 Nov 2003 16:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOR7-0003gE-Nf; Mon, 24 Nov 2003 16:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOQL-0003XN-I6 for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02463 for ; Mon, 24 Nov 2003 16:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOQJ-0005WY-00 for simple@ietf.org; Mon, 24 Nov 2003 16:39:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOOQI-0005VA-00 for simple@ietf.org; Mon, 24 Nov 2003 16:39:11 -0500 Received: from dynamicsoft.com ([63.113.46.45]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAOLawca021889; Mon, 24 Nov 2003 16:36:58 -0500 (EST) Message-ID: <3FC279F6.7040001@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Dean Willis , simple@ietf.org Subject: Re: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 16:36:54 -0500 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I went and did some testing with a handful of different NATs and poked > around on documentation for more. Here's the initial results I found - if > folks can point me to stuff that contradicts this, I would be grateful .... > > Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, > HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 > seconds). Due to the multiples retires and such it takes several minutes > after this before anything is really killed. > > The NAT and FW I looked at (mostly Cisco and Linksys but few others too) > seem to also set the TCP timeouts at 2 hours plus a bit. But these are configurable, right? The issue, unfortunately, is what is out there in the real world. We had a nasty experience with a large enterprise that had them set really low, and I am wondering how frequently these timeouts are adjusted down in the interests of "security". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 16:41:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02708 for ; Mon, 24 Nov 2003 16:41:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOS8-0003mc-Nu for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOLf4l7014532 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 16:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOS8-0003mF-FV for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 16:41:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02634; Mon, 24 Nov 2003 16:40:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOS3-0005ap-00; Mon, 24 Nov 2003 16:40:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOOS2-0005Zh-00; Mon, 24 Nov 2003 16:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOR7-0003gE-Nf; Mon, 24 Nov 2003 16:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOQL-0003XN-I6 for simple@optimus.ietf.org; Mon, 24 Nov 2003 16:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02463 for ; Mon, 24 Nov 2003 16:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOQJ-0005WY-00 for simple@ietf.org; Mon, 24 Nov 2003 16:39:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOOQI-0005VA-00 for simple@ietf.org; Mon, 24 Nov 2003 16:39:11 -0500 Received: from dynamicsoft.com ([63.113.46.45]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAOLawca021889; Mon, 24 Nov 2003 16:36:58 -0500 (EST) Message-ID: <3FC279F6.7040001@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Dean Willis , simple@ietf.org Subject: Re: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 16:36:54 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I went and did some testing with a handful of different NATs and poked > around on documentation for more. Here's the initial results I found - if > folks can point me to stuff that contradicts this, I would be grateful .... > > Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, > HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 > seconds). Due to the multiples retires and such it takes several minutes > after this before anything is really killed. > > The NAT and FW I looked at (mostly Cisco and Linksys but few others too) > seem to also set the TCP timeouts at 2 hours plus a bit. But these are configurable, right? The issue, unfortunately, is what is out there in the real world. We had a nasty experience with a large enterprise that had them set really low, and I am wondering how frequently these timeouts are adjusted down in the interests of "security". -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 18:06:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09039; Mon, 24 Nov 2003 18:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOPnR-0000DL-00; Mon, 24 Nov 2003 18:07:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOPnQ-0000DI-00; Mon, 24 Nov 2003 18:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPnJ-00013Q-G6; Mon, 24 Nov 2003 18:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPmw-00012L-7n for simple@optimus.ietf.org; Mon, 24 Nov 2003 18:06:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08957 for ; Mon, 24 Nov 2003 18:06:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOPmt-0000CR-00 for simple@ietf.org; Mon, 24 Nov 2003 18:06:35 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOPmt-0000C5-00 for simple@ietf.org; Mon, 24 Nov 2003 18:06:35 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2003 15:07:29 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAON5vAv007759; Mon, 24 Nov 2003 15:06:03 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEF62763; Mon, 24 Nov 2003 18:05:56 -0500 (EST) Message-ID: <3FC28ED4.3010201@cisco.com> 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: Robert Sparks CC: simple@ietf.org References: <1069305486.937.84.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Review of the filtering requirements work Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 18:05:56 -0500 Content-Transfer-Encoding: 7bit Robert asked me to review the filtering requirements documents. I have done so, with comments following. In general the content looks reasonable, but I did find a number small and moderate sized problems. I believe all can be easily remedied. Paul - draft-ietf-simple-winfo-filter-reqs-00.txt Section 3.1: the last sentence isn't a valid English sentence. I suggest something like: "It MUST be possible for the client to define different rules for different purposes using a common filtering mechanism." Section 3.3: s/criteria/criterion/ Section 3.4: There are what appear to be three requirement prior to 3.4.1. Suggest renumbering the existing 3.4.* starting with 3.4.4, and then numbering these three requirements as 3.4.1, 3.4.2, and 3.4.3. Sections 3.4.3 and 3.4.4: These sections use terms "expiration" and "duration of subscription" that apparently are intended to align with the terms "expiration" and "duration-subscribed" in draft-ietf-simple-winfo-format-04. However the definitions used here are sufficiently different to raise doubts. These should be carefully aligned. - draft-ietf-simple-pres-filter-reqs-02.txt The requirements are apparently intended to be identified as REQ 01, REQ 02, ... but currently they are all REQ xx. Section 3.2: there is one requirement referencing a presence list and another referencing sub-lists. There is no longer anything called a presence-list - that concept has been replaced by event-lists, which are not specific to presence. Filters criteria that explicitly refer to lists will need to be processed by the event list server, while it may be that other presence related criteria need to be processed by the eventual presence server and may not be understood by the event list server. These requirements should be refined to ensure that they actually make sense and are achievable in the context of likely event list server implementations. Section 3.3, first REQ: I don't find this entirely clear. I think it is trying to say that filter criteria may only reference elements that the subscriber is permitted to request as notification content. If I'm right you could improve the requirement by saying that. If I'm wrong, then the requirement really didn't work for me. Section 3.3, last REQ: s/combine/combines/ Section 4.1.1: The three requirements in this section all seem to be attempting to say the same thing in different ways. So I think this is just one requirement. Some of the text from all three can be combined into that one. Section 5.1: there seems to be a large amount of overlap between this and section 3.2. I'm not sure the overlap is total, but it is confusing. My comments for 3.2 also apply here. - Inconsistencies between the two documents: In draft-ietf-simple-winfo-filter-reqs-00 the requirements are identified only by the section in which they are placed. In draft-ietf-simple-pres-filter-reqs-02 there are multiple requirements per numbered section, identified as REQ xx. Either format is workable, and there is no inherent need for the two documents to be consistent, but because they are otherwise similar documents it would be best for them to adopt a similar style. For requirement docs in general the trend seems to be to use something like REQ-xx, so that may be best. Section 5 of winfo-filter-reqs is content free. Yet the contents of the corresponding section 6 of pres-filter-reqs, with the exception of the last requirement pertaining to lists, seems to be applicable. Why not align them? Section 4.2 of pres-filter-reqs is gratuitously different than sections 4.2, 4.3, and 4.4 of winfo-filter-reqs. It appears that the same requirements should apply to both. For the most part the requirements in pres-filter-reqs seem better. They at least should be aligned. ============================================================================= Robert Sparks wrote: > Paul - > > Would you please review > > draft-ietf-simple-winfo-filter-reqs-00.txt > and > draft-ietf-simple-pres-filter-reqs-02.txt > > from a technical perspective (do the drafts accurately > reflect list discussion and are they complete) and send > comments to the SIMPLE list by Nov 26? > > The drafts are short - I do not expect review of the both of > them to take more than a couple of hours. > > I'm going to task other people to do I-D nit reviews, but if > you have time to do that as well, more eyes are better than > fewer. > > Thanks! > RjS > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 18:07:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09115 for ; Mon, 24 Nov 2003 18:07:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPnV-00017R-4D for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 18:07:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAON7CJl004287 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 18:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPnU-000172-N3 for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 18:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09039; Mon, 24 Nov 2003 18:06:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOPnR-0000DL-00; Mon, 24 Nov 2003 18:07:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOPnQ-0000DI-00; Mon, 24 Nov 2003 18:07:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPnJ-00013Q-G6; Mon, 24 Nov 2003 18:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOPmw-00012L-7n for simple@optimus.ietf.org; Mon, 24 Nov 2003 18:06:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08957 for ; Mon, 24 Nov 2003 18:06:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOPmt-0000CR-00 for simple@ietf.org; Mon, 24 Nov 2003 18:06:35 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOPmt-0000C5-00 for simple@ietf.org; Mon, 24 Nov 2003 18:06:35 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Nov 2003 15:07:29 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAON5vAv007759; Mon, 24 Nov 2003 15:06:03 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEF62763; Mon, 24 Nov 2003 18:05:56 -0500 (EST) Message-ID: <3FC28ED4.3010201@cisco.com> 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: Robert Sparks CC: simple@ietf.org References: <1069305486.937.84.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Review of the filtering requirements work Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 18:05:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert asked me to review the filtering requirements documents. I have done so, with comments following. In general the content looks reasonable, but I did find a number small and moderate sized problems. I believe all can be easily remedied. Paul - draft-ietf-simple-winfo-filter-reqs-00.txt Section 3.1: the last sentence isn't a valid English sentence. I suggest something like: "It MUST be possible for the client to define different rules for different purposes using a common filtering mechanism." Section 3.3: s/criteria/criterion/ Section 3.4: There are what appear to be three requirement prior to 3.4.1. Suggest renumbering the existing 3.4.* starting with 3.4.4, and then numbering these three requirements as 3.4.1, 3.4.2, and 3.4.3. Sections 3.4.3 and 3.4.4: These sections use terms "expiration" and "duration of subscription" that apparently are intended to align with the terms "expiration" and "duration-subscribed" in draft-ietf-simple-winfo-format-04. However the definitions used here are sufficiently different to raise doubts. These should be carefully aligned. - draft-ietf-simple-pres-filter-reqs-02.txt The requirements are apparently intended to be identified as REQ 01, REQ 02, ... but currently they are all REQ xx. Section 3.2: there is one requirement referencing a presence list and another referencing sub-lists. There is no longer anything called a presence-list - that concept has been replaced by event-lists, which are not specific to presence. Filters criteria that explicitly refer to lists will need to be processed by the event list server, while it may be that other presence related criteria need to be processed by the eventual presence server and may not be understood by the event list server. These requirements should be refined to ensure that they actually make sense and are achievable in the context of likely event list server implementations. Section 3.3, first REQ: I don't find this entirely clear. I think it is trying to say that filter criteria may only reference elements that the subscriber is permitted to request as notification content. If I'm right you could improve the requirement by saying that. If I'm wrong, then the requirement really didn't work for me. Section 3.3, last REQ: s/combine/combines/ Section 4.1.1: The three requirements in this section all seem to be attempting to say the same thing in different ways. So I think this is just one requirement. Some of the text from all three can be combined into that one. Section 5.1: there seems to be a large amount of overlap between this and section 3.2. I'm not sure the overlap is total, but it is confusing. My comments for 3.2 also apply here. - Inconsistencies between the two documents: In draft-ietf-simple-winfo-filter-reqs-00 the requirements are identified only by the section in which they are placed. In draft-ietf-simple-pres-filter-reqs-02 there are multiple requirements per numbered section, identified as REQ xx. Either format is workable, and there is no inherent need for the two documents to be consistent, but because they are otherwise similar documents it would be best for them to adopt a similar style. For requirement docs in general the trend seems to be to use something like REQ-xx, so that may be best. Section 5 of winfo-filter-reqs is content free. Yet the contents of the corresponding section 6 of pres-filter-reqs, with the exception of the last requirement pertaining to lists, seems to be applicable. Why not align them? Section 4.2 of pres-filter-reqs is gratuitously different than sections 4.2, 4.3, and 4.4 of winfo-filter-reqs. It appears that the same requirements should apply to both. For the most part the requirements in pres-filter-reqs seem better. They at least should be aligned. ============================================================================= Robert Sparks wrote: > Paul - > > Would you please review > > draft-ietf-simple-winfo-filter-reqs-00.txt > and > draft-ietf-simple-pres-filter-reqs-02.txt > > from a technical perspective (do the drafts accurately > reflect list discussion and are they complete) and send > comments to the SIMPLE list by Nov 26? > > The drafts are short - I do not expect review of the both of > them to take more than a couple of hours. > > I'm going to task other people to do I-D nit reviews, but if > you have time to do that as well, more eyes are better than > fewer. > > Thanks! > RjS > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 18:26:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10881; Mon, 24 Nov 2003 18:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQ6h-0000dA-00; Mon, 24 Nov 2003 18:27:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOQ6h-0000d7-00; Mon, 24 Nov 2003 18:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQ6g-0002h1-1s; Mon, 24 Nov 2003 18:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANXmK-00010H-Un for simple@optimus.ietf.org; Sat, 22 Nov 2003 08:26:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11089 for ; Sat, 22 Nov 2003 08:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANXmJ-0004je-00 for simple@ietf.org; Sat, 22 Nov 2003 08:26:23 -0500 Received: from relay2.masterhost.ru ([217.16.16.83]) by ietf-mx with smtp (Exim 4.12) id 1ANXmJ-0004jO-00 for simple@ietf.org; Sat, 22 Nov 2003 08:26:23 -0500 Received: (qmail 32340 invoked from network); 22 Nov 2003 13:25:49 -0000 Received: from smtp.masterhost.ru (217.16.16.42) by relay2.masterhost.ru with SMTP; 22 Nov 2003 13:25:49 -0000 Received: (qmail 72821 invoked from network); 22 Nov 2003 13:25:49 -0000 Received: from unknown (HELO mc8.mediachase.local) (193.124.6.250) by smtp.masterhost.ru with SMTP; 22 Nov 2003 13:25:49 -0000 From: Nadezhda Fedorova Reply-To: Nadezhda Fedorova X-Priority: 3 (Normal) Message-ID: <5514680559.20031122152824@war.ru> To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Questions about SIMPLE Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Nov 2003 15:28:24 +0200 Content-Transfer-Encoding: 7bit Hello all, Could you please answer some questions about SIMPLE? I need to make IM System based on SIP and SIMPLE, so I've read a lot of documents about SIMPLE and didn't find answers to them. Please answer me if you can. Here are the questions: 1. Is it possible to use resource lists (RL) not only for defining list of my buddies and subscribing to events from them, but e.g. for inviting many people to a dialog, or for sending a message to all of them simultaneously? If it is, then what must be the behaviour of UAC and UAS when UAC sends a message to all buddies from his RL and some of buddies are offline and some online? 2. Are there any common mechanisms (rules) for sending offline messages (I mean rules for sending a message to a user when he is offline)? 3. How can I SUBSCRIBE to all events from a resource? -- Best regards, Nadezhda mailto:nadya@war.ru mailto:nadya@mediachase.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 18:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10947 for ; Mon, 24 Nov 2003 18:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQ6l-0002hv-NW for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 18:27:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAONR792010403 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 18:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQ6l-0002hi-Ho for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 18:27:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10881; Mon, 24 Nov 2003 18:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOQ6h-0000dA-00; Mon, 24 Nov 2003 18:27:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOQ6h-0000d7-00; Mon, 24 Nov 2003 18:27:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOQ6g-0002h1-1s; Mon, 24 Nov 2003 18:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANXmK-00010H-Un for simple@optimus.ietf.org; Sat, 22 Nov 2003 08:26:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11089 for ; Sat, 22 Nov 2003 08:26:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANXmJ-0004je-00 for simple@ietf.org; Sat, 22 Nov 2003 08:26:23 -0500 Received: from relay2.masterhost.ru ([217.16.16.83]) by ietf-mx with smtp (Exim 4.12) id 1ANXmJ-0004jO-00 for simple@ietf.org; Sat, 22 Nov 2003 08:26:23 -0500 Received: (qmail 32340 invoked from network); 22 Nov 2003 13:25:49 -0000 Received: from smtp.masterhost.ru (217.16.16.42) by relay2.masterhost.ru with SMTP; 22 Nov 2003 13:25:49 -0000 Received: (qmail 72821 invoked from network); 22 Nov 2003 13:25:49 -0000 Received: from unknown (HELO mc8.mediachase.local) (193.124.6.250) by smtp.masterhost.ru with SMTP; 22 Nov 2003 13:25:49 -0000 From: Nadezhda Fedorova Reply-To: Nadezhda Fedorova X-Priority: 3 (Normal) Message-ID: <5514680559.20031122152824@war.ru> To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Questions about SIMPLE Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 22 Nov 2003 15:28:24 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, Could you please answer some questions about SIMPLE? I need to make IM System based on SIP and SIMPLE, so I've read a lot of documents about SIMPLE and didn't find answers to them. Please answer me if you can. Here are the questions: 1. Is it possible to use resource lists (RL) not only for defining list of my buddies and subscribing to events from them, but e.g. for inviting many people to a dialog, or for sending a message to all of them simultaneously? If it is, then what must be the behaviour of UAC and UAS when UAC sends a message to all buddies from his RL and some of buddies are offline and some online? 2. Are there any common mechanisms (rules) for sending offline messages (I mean rules for sending a message to a user when he is offline)? 3. How can I SUBSCRIBE to all events from a resource? -- Best regards, Nadezhda mailto:nadya@war.ru mailto:nadya@mediachase.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 19:53:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14408; Mon, 24 Nov 2003 19:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORSx-00028G-00; Mon, 24 Nov 2003 19:54:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AORSx-00028B-00; Mon, 24 Nov 2003 19:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORSr-0008K3-K9; Mon, 24 Nov 2003 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORS1-0008Ip-8W for simple@optimus.ietf.org; Mon, 24 Nov 2003 19:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14358 for ; Mon, 24 Nov 2003 19:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORRz-00027N-00 for simple@ietf.org; Mon, 24 Nov 2003 19:53:07 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AORRy-00026b-00 for simple@ietf.org; Mon, 24 Nov 2003 19:53:06 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAP0qYjq021435; Mon, 24 Nov 2003 16:52:35 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKF67865; Mon, 24 Nov 2003 16:52:33 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) From: Cullen Jennings To: Jonathan Rosenberg CC: Dean Willis , Message-ID: In-Reply-To: <3FC279F6.7040001@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 16:52:33 -0800 Content-Transfer-Encoding: 7bit On 11/24/03 1:36 PM, "Jonathan Rosenberg" wrote: > > > Cullen Jennings wrote: > >> I went and did some testing with a handful of different NATs and poked >> around on documentation for more. Here's the initial results I found - if >> folks can point me to stuff that contradicts this, I would be grateful .... >> >> Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, >> HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 >> seconds). Due to the multiples retires and such it takes several minutes >> after this before anything is really killed. >> >> The NAT and FW I looked at (mostly Cisco and Linksys but few others too) >> seem to also set the TCP timeouts at 2 hours plus a bit. > > But these are configurable, right? The issue, unfortunately, is what > is out there in the real world. We had a nasty experience with a large > enterprise that had them set really low, and I am wondering how > frequently these timeouts are adjusted down in the interests of > "security". > > -Jonathan R. Good question - I don't know. Some (cough cough) organizations have configured their firewall to not allow any UDP through which puts a real damper on VoIP. As the saying goes, I see 10 types of people a) The ones that have not changed the settings from the defaults b) The ones that have changed the settings. Hopefully these are capable of changing them to setting that will work if they really feel like it. If they don't feel like it, them I have no interest in trying to circumvent the policy they want to apply. I suspect that really short lived TCP timeouts are not extremely common but have no way to prove that one way or another. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Nov 24 19:54:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14448 for ; Mon, 24 Nov 2003 19:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORT0-0008M2-GC for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 19:54:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP0sAZX032110 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 19:54:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORT0-0008Lp-Cx for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 19:54:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14408; Mon, 24 Nov 2003 19:53:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORSx-00028G-00; Mon, 24 Nov 2003 19:54:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AORSx-00028B-00; Mon, 24 Nov 2003 19:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORSr-0008K3-K9; Mon, 24 Nov 2003 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AORS1-0008Ip-8W for simple@optimus.ietf.org; Mon, 24 Nov 2003 19:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14358 for ; Mon, 24 Nov 2003 19:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AORRz-00027N-00 for simple@ietf.org; Mon, 24 Nov 2003 19:53:07 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AORRy-00026b-00 for simple@ietf.org; Mon, 24 Nov 2003 19:53:06 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAP0qYjq021435; Mon, 24 Nov 2003 16:52:35 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKF67865; Mon, 24 Nov 2003 16:52:33 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) From: Cullen Jennings To: Jonathan Rosenberg CC: Dean Willis , Message-ID: In-Reply-To: <3FC279F6.7040001@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 16:52:33 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 11/24/03 1:36 PM, "Jonathan Rosenberg" wrote: > > > Cullen Jennings wrote: > >> I went and did some testing with a handful of different NATs and poked >> around on documentation for more. Here's the initial results I found - if >> folks can point me to stuff that contradicts this, I would be grateful .... >> >> Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, >> HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 >> seconds). Due to the multiples retires and such it takes several minutes >> after this before anything is really killed. >> >> The NAT and FW I looked at (mostly Cisco and Linksys but few others too) >> seem to also set the TCP timeouts at 2 hours plus a bit. > > But these are configurable, right? The issue, unfortunately, is what > is out there in the real world. We had a nasty experience with a large > enterprise that had them set really low, and I am wondering how > frequently these timeouts are adjusted down in the interests of > "security". > > -Jonathan R. Good question - I don't know. Some (cough cough) organizations have configured their firewall to not allow any UDP through which puts a real damper on VoIP. As the saying goes, I see 10 types of people a) The ones that have not changed the settings from the defaults b) The ones that have changed the settings. Hopefully these are capable of changing them to setting that will work if they really feel like it. If they don't feel like it, them I have no interest in trying to circumvent the policy they want to apply. I suspect that really short lived TCP timeouts are not extremely common but have no way to prove that one way or another. Cullen _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Nov 24 21:44:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17419; Mon, 24 Nov 2003 21:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOTBV-0003bB-00; Mon, 24 Nov 2003 21:44:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOTBV-0003b8-00; Mon, 24 Nov 2003 21:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTBJ-0004fl-U9; Mon, 24 Nov 2003 21:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTAT-0004Vy-2N for simple@optimus.ietf.org; Mon, 24 Nov 2003 21:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17352 for ; Mon, 24 Nov 2003 21:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOTAQ-0003aR-00 for simple@ietf.org; Mon, 24 Nov 2003 21:43:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AOTAP-0003aO-00 for simple@ietf.org; Mon, 24 Nov 2003 21:43:05 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAP2h0U6019853; Mon, 24 Nov 2003 21:43:00 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAP2gxf12639; Mon, 24 Nov 2003 21:42:59 -0500 Message-ID: <3FC2C1B1.3070408@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Jonathan Rosenberg , Dean Willis , simple@ietf.org Subject: Re: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 21:42:57 -0500 Content-Transfer-Encoding: 7bit I've just experienced a NAT/SIP-enabled DSL firewall that had a default value of 5 minutes of inactivity timeout, fortunately configurable. Cullen Jennings wrote: > On 11/24/03 1:36 PM, "Jonathan Rosenberg" wrote: > > >> >>Cullen Jennings wrote: >> >> >>>I went and did some testing with a handful of different NATs and poked >>>around on documentation for more. Here's the initial results I found - if >>>folks can point me to stuff that contradicts this, I would be grateful .... >>> >>>Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, >>>HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 >>>seconds). Due to the multiples retires and such it takes several minutes >>>after this before anything is really killed. >>> >>>The NAT and FW I looked at (mostly Cisco and Linksys but few others too) >>>seem to also set the TCP timeouts at 2 hours plus a bit. >> >>But these are configurable, right? The issue, unfortunately, is what >>is out there in the real world. We had a nasty experience with a large >>enterprise that had them set really low, and I am wondering how >>frequently these timeouts are adjusted down in the interests of >>"security". >> >>-Jonathan R. > > > Good question - I don't know. Some (cough cough) organizations have > configured their firewall to not allow any UDP through which puts a real > damper on VoIP. > > As the saying goes, I see 10 types of people > > a) The ones that have not changed the settings from the defaults > > b) The ones that have changed the settings. Hopefully these are capable of > changing them to setting that will work if they really feel like it. If they > don't feel like it, them I have no interest in trying to circumvent the > policy they want to apply. > > I suspect that really short lived TCP timeouts are not extremely common but > have no way to prove that one way or another. > > 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 exim@www1.ietf.org Mon Nov 24 21:44:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17448 for ; Mon, 24 Nov 2003 21:44:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTBZ-0004hq-Bt for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 21:44:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP2iHn5018084 for simple-archive@odin.ietf.org; Mon, 24 Nov 2003 21:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTBZ-0004hb-8Y for simple-web-archive@optimus.ietf.org; Mon, 24 Nov 2003 21:44:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17419; Mon, 24 Nov 2003 21:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOTBV-0003bB-00; Mon, 24 Nov 2003 21:44:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOTBV-0003b8-00; Mon, 24 Nov 2003 21:44:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTBJ-0004fl-U9; Mon, 24 Nov 2003 21:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOTAT-0004Vy-2N for simple@optimus.ietf.org; Mon, 24 Nov 2003 21:43:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17352 for ; Mon, 24 Nov 2003 21:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOTAQ-0003aR-00 for simple@ietf.org; Mon, 24 Nov 2003 21:43:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AOTAP-0003aO-00 for simple@ietf.org; Mon, 24 Nov 2003 21:43:05 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAP2h0U6019853; Mon, 24 Nov 2003 21:43:00 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAP2gxf12639; Mon, 24 Nov 2003 21:42:59 -0500 Message-ID: <3FC2C1B1.3070408@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Jonathan Rosenberg , Dean Willis , simple@ietf.org Subject: Re: NAT/FW TCP mapping timeouts ( Was Re: [Simple] Objects to NATs kill TCP connection ) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Nov 2003 21:42:57 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've just experienced a NAT/SIP-enabled DSL firewall that had a default value of 5 minutes of inactivity timeout, fortunately configurable. Cullen Jennings wrote: > On 11/24/03 1:36 PM, "Jonathan Rosenberg" wrote: > > >> >>Cullen Jennings wrote: >> >> >>>I went and did some testing with a handful of different NATs and poked >>>around on documentation for more. Here's the initial results I found - if >>>folks can point me to stuff that contradicts this, I would be grateful .... >>> >>>Just about every OS I can muck with, (Windows 98,2000,XP, Linux, Solaris, >>>HPUX) seems to set the default TCP keep alive timer to 2 hours (7200 >>>seconds). Due to the multiples retires and such it takes several minutes >>>after this before anything is really killed. >>> >>>The NAT and FW I looked at (mostly Cisco and Linksys but few others too) >>>seem to also set the TCP timeouts at 2 hours plus a bit. >> >>But these are configurable, right? The issue, unfortunately, is what >>is out there in the real world. We had a nasty experience with a large >>enterprise that had them set really low, and I am wondering how >>frequently these timeouts are adjusted down in the interests of >>"security". >> >>-Jonathan R. > > > Good question - I don't know. Some (cough cough) organizations have > configured their firewall to not allow any UDP through which puts a real > damper on VoIP. > > As the saying goes, I see 10 types of people > > a) The ones that have not changed the settings from the defaults > > b) The ones that have changed the settings. Hopefully these are capable of > changing them to setting that will work if they really feel like it. If they > don't feel like it, them I have no interest in trying to circumvent the > policy they want to apply. > > I suspect that really short lived TCP timeouts are not extremely common but > have no way to prove that one way or another. > > 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-admin@ietf.org Tue Nov 25 02:54:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07333; Tue, 25 Nov 2003 02:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOY1U-0007Qo-00; Tue, 25 Nov 2003 02:54:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOY1U-0007Qj-00; Tue, 25 Nov 2003 02:54:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOY1K-0002DM-7R; Tue, 25 Nov 2003 02:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOY0a-0002AD-NF for simple@optimus.ietf.org; Tue, 25 Nov 2003 02:53:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07300 for ; Tue, 25 Nov 2003 02:53:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOY0K-0007Q0-00 for simple@ietf.org; Tue, 25 Nov 2003 02:53:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOY0J-0007Px-00 for simple@ietf.org; Tue, 25 Nov 2003 02:52:59 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP7qx627737 for ; Tue, 25 Nov 2003 09:52:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 09:52:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 09:52:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B108@esebe019.ntc.nokia.com> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOyu9AGZm3o3FYFSTmAhFKz7wH5GQAbKZNw To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 07:52:59.0843 (UTC) FILETIME=[255DA130:01C3B329] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:52:59 +0200 Content-Transfer-Encoding: quoted-printable Hi Miguel, I don't agree with you. The relay case will be seen as an extension of = MS(R)P and therefore all methods to support relays should be defined in = that document. If endpoint implementers want to support relays for NAT traversal, then = they better implement whatever is documented in the relay document. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Miguel A. Garcia > Sent: 24.November.2003 20:48 > To: Ben Campbell > Cc: Simple WG > Subject: [Simple] BIND and relays documentation >=20 >=20 > Hi: >=20 > A question about the recent decision to split the MSRP=20 > protocol into a=20 > relay-less document and a document that details the use of relays. >=20 > I would like to understand if the idea is to document the=20 > BIND primitive=20 > in the relay-less document or in the relayful document. >=20 > Some folks may argue that the BIND primitive is only used in the case=20 > there are relays in the path, and as such, it should be documented in=20 > the relays document. However, in doing so, we may risk that=20 > end points=20 > will not implement the BIND primitive ever, and therefore will not=20 > support the operation through relays. >=20 > I am in favour of documenting the BIND primitive in the core MSRP=20 > document, in spite that the relay operation will be described in the=20 > relays document. >=20 > Is this something that the working group is thinking? >=20 > /Miguel > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 >=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 exim@www1.ietf.org Tue Nov 25 02:54:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07372 for ; Tue, 25 Nov 2003 02:54:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOY1Z-0002FQ-RL for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 02:54:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP7sHAY008637 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 02:54:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOY1Y-0002FD-U0 for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 02:54:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07333; Tue, 25 Nov 2003 02:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOY1U-0007Qo-00; Tue, 25 Nov 2003 02:54:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOY1U-0007Qj-00; Tue, 25 Nov 2003 02:54:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOY1K-0002DM-7R; Tue, 25 Nov 2003 02:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOY0a-0002AD-NF for simple@optimus.ietf.org; Tue, 25 Nov 2003 02:53:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07300 for ; Tue, 25 Nov 2003 02:53:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOY0K-0007Q0-00 for simple@ietf.org; Tue, 25 Nov 2003 02:53:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOY0J-0007Px-00 for simple@ietf.org; Tue, 25 Nov 2003 02:52:59 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP7qx627737 for ; Tue, 25 Nov 2003 09:52:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 09:52:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 09:52:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B108@esebe019.ntc.nokia.com> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOyu9AGZm3o3FYFSTmAhFKz7wH5GQAbKZNw To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 07:52:59.0843 (UTC) FILETIME=[255DA130:01C3B329] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:52:59 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Miguel, I don't agree with you. The relay case will be seen as an extension of = MS(R)P and therefore all methods to support relays should be defined in = that document. If endpoint implementers want to support relays for NAT traversal, then = they better implement whatever is documented in the relay document. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Miguel A. Garcia > Sent: 24.November.2003 20:48 > To: Ben Campbell > Cc: Simple WG > Subject: [Simple] BIND and relays documentation >=20 >=20 > Hi: >=20 > A question about the recent decision to split the MSRP=20 > protocol into a=20 > relay-less document and a document that details the use of relays. >=20 > I would like to understand if the idea is to document the=20 > BIND primitive=20 > in the relay-less document or in the relayful document. >=20 > Some folks may argue that the BIND primitive is only used in the case=20 > there are relays in the path, and as such, it should be documented in=20 > the relays document. However, in doing so, we may risk that=20 > end points=20 > will not implement the BIND primitive ever, and therefore will not=20 > support the operation through relays. >=20 > I am in favour of documenting the BIND primitive in the core MSRP=20 > document, in spite that the relay operation will be described in the=20 > relays document. >=20 > Is this something that the working group is thinking? >=20 > /Miguel > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 >=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-admin@ietf.org Tue Nov 25 03:13:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07944; Tue, 25 Nov 2003 03:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYKh-0007iO-00; Tue, 25 Nov 2003 03:14:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOYKg-0007iL-00; Tue, 25 Nov 2003 03:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYKf-00038K-4u; Tue, 25 Nov 2003 03:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYK0-00037Z-0Y for simple@optimus.ietf.org; Tue, 25 Nov 2003 03:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07934 for ; Tue, 25 Nov 2003 03:13:06 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYJx-0007i7-00 for simple@ietf.org; Tue, 25 Nov 2003 03:13:17 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOYJw-0007i4-00 for simple@ietf.org; Tue, 25 Nov 2003 03:13:17 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP8DEA21634 for ; Tue, 25 Nov 2003 10:13:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 10:13:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 10:13:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B109@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOyyukBMhSrDLK8TJakInT+WRSDxwAXx05g To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 08:13:12.0460 (UTC) FILETIME=[F8244CC0:01C3B32B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 10:13:11 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 24.November.2003 22:38 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > This issue consumed a lot of discussion during the Minneapolis IETF. > >=20 > > The current xcap-auth specification adds support for=20 > exceptions within=20 > > the applies-to statements. This allows for a way to say=20 > that a statement=20 > > applies to all the users in a domain or list EXCEPT the=20 > listed set of=20 > > users. This is useful for specifying things like "I want to grant=20 > > permission to everyone in dynamicsoft.com except for Bob".=20 > Presumably=20 > > Bob is an annoying guy and I just don't want to grant him=20 > permission. > >=20 > > Now, a few points need to be made clear about the=20 > exceptions processing. > >=20 > > Firstly, having things like this: > >=20 > > > > > > > > sip:joe@example.com > > > > > >=20 > > is completely useless. The reason is that it is really easy=20 > to obtain=20 > > new names from many namespace providers. As a result, you=20 > may thikn you=20 > > are blocking Joe, but he just goes off, gets a new URI from=20 > yahoo, and=20 > > your permission statement is useless. > > Indeed, the entire notion of except clauses is only useful=20 > if you assume=20 > > that there are cases where it is hard to obtain new=20 > identifiers. There=20 > > was some dispute about whether this is a good assumnption=20 > or not. I, and=20 > > some others, do believe that in many enterprises, it is a good=20 > > assumption that obtaining a new enterprise identifier is not easy. >=20 > While agree that outside of walled-gardens your example is not very=20 > useful, I do think this is very useful when your applies-to=20 > is scoped to=20 > a domain. >=20 > This is not limited to enterprise deployments. It may be true=20 > that some=20 > providers give away identities for free, it is not the case=20 > that _all_=20 > providers do this. In fact, I think the whole argument that you don't=20 > need exceptions becauses identities are free is bogus. >=20 > >=20 > > A second point on exceptions. If an exception represents a=20 > list, and you=20 > > can't dereference that list, then you have to drop the=20 > entire permission=20 > > statement. This is to ensure privacy-safety, so that=20 > information is not=20 > > leaked under any failure condition. > >=20 > > Finally, it needs to be clarified that exceptions still result in=20 > > additive permissions. So, for example, if I have two=20 > staements like this: > >=20 > > > > example.com > > > > sip:sally@example.com > > > > > >=20 > > > >=20 > > and > >=20 > > > > example.com > > > > sip:bob@example.com > > > > > >=20 > > > >=20 > >=20 > >=20 > > That if EITHER Sally or Bob subscribes, they will be=20 > granted permission=20 > > to subscribe. Thats because, if Bob subscribes, the first policy=20 > > statement applies to him, resulting in his subscription=20 > being accepted.=20 > > If Sally subscribes, the second applies to her, and her=20 > subscription is=20 > > accepted. > >=20 > > If you try and make except clauses carry across permission=20 > statements,=20 > > you end up in a place where these statements are no longer=20 > additive, and=20 > > you are not privacy safe anymore. > >=20 > > Now, even given these clarifications, the geopriv group is=20 > not planning=20 > > on specifying an except condition at this time. Though they=20 > consider it=20 > > useful, its been ruled out of scope for the initial policy=20 > document.=20 > > Thus, if we wish to align, we would need to also rule it=20 > out of scope in=20 > > the initial version of the specification. > >=20 > > That does not mean it could never be done; indeed, it would be my=20 > > proposal to more or less immediately have a draft defining it, and=20 > > progress this just behind the main specs. > >=20 > > IMHO, it is worth getting alignment to let this feature=20 > move forward in=20 > > a separate specification, behind the main one. > >=20 > > Comments and thoughts? >=20 > I personally do not think we can live without exceptions, even for a=20 > little while. Since the additive approach does not allow me to=20 > explicitly black-list someone and have that override any other=20 > permissions, then the only way I could create a rule that allowed=20 > everyone from example.com except alice would be to list every single=20 > member of example.com explicitly. This is bad enough from a=20 > convenience=20 > perspective--but in reality it is very unlikely example.com=20 > will share=20 > its membership roster with me, so I could not do this even if=20 > I wanted to. The way it works today is that you have a list of presentities and a = list of watchers. The list of watchers is what the issues are about. In = most systems today, the list of watchers is a mirror to the list of = presentities, and therefore does not include everyone is a domain.=20 I think it is ok for now to give permissions to individual watchers as = selected by the presentity. We are not at a stage in presence systems = where we want to allow everyone at a domain to view someone's presence = excepting individual x and y. But more like 15 to 20 individuals that = the presentity mostly interacts with in that domain. So, instead of allowing, for example, everyone at example.com except for = Bob. I can pick john, alice, ben and adam from example.com that I = interact with and want to allow to be my watchers, and create = permissions for them. This leaves out bob along with everyone else at = example.com. I think this is good enough. Regards, Hisham >=20 > I am willing to live with limiting exceptions expressions to=20 > things that=20 > never require external resolution. >=20 > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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 exim@www1.ietf.org Tue Nov 25 03:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07972 for ; Tue, 25 Nov 2003 03:14:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYKk-00039L-E6 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 03:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP8E6sx012107 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 03:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYKk-00039C-4F for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 03:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07944; Tue, 25 Nov 2003 03:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYKh-0007iO-00; Tue, 25 Nov 2003 03:14:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOYKg-0007iL-00; Tue, 25 Nov 2003 03:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYKf-00038K-4u; Tue, 25 Nov 2003 03:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYK0-00037Z-0Y for simple@optimus.ietf.org; Tue, 25 Nov 2003 03:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07934 for ; Tue, 25 Nov 2003 03:13:06 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYJx-0007i7-00 for simple@ietf.org; Tue, 25 Nov 2003 03:13:17 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOYJw-0007i4-00 for simple@ietf.org; Tue, 25 Nov 2003 03:13:17 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP8DEA21634 for ; Tue, 25 Nov 2003 10:13:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 10:13:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 10:13:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B109@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOyyukBMhSrDLK8TJakInT+WRSDxwAXx05g To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 08:13:12.0460 (UTC) FILETIME=[F8244CC0:01C3B32B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 10:13:11 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 24.November.2003 22:38 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > This issue consumed a lot of discussion during the Minneapolis IETF. > >=20 > > The current xcap-auth specification adds support for=20 > exceptions within=20 > > the applies-to statements. This allows for a way to say=20 > that a statement=20 > > applies to all the users in a domain or list EXCEPT the=20 > listed set of=20 > > users. This is useful for specifying things like "I want to grant=20 > > permission to everyone in dynamicsoft.com except for Bob".=20 > Presumably=20 > > Bob is an annoying guy and I just don't want to grant him=20 > permission. > >=20 > > Now, a few points need to be made clear about the=20 > exceptions processing. > >=20 > > Firstly, having things like this: > >=20 > > > > > > > > sip:joe@example.com > > > > > >=20 > > is completely useless. The reason is that it is really easy=20 > to obtain=20 > > new names from many namespace providers. As a result, you=20 > may thikn you=20 > > are blocking Joe, but he just goes off, gets a new URI from=20 > yahoo, and=20 > > your permission statement is useless. > > Indeed, the entire notion of except clauses is only useful=20 > if you assume=20 > > that there are cases where it is hard to obtain new=20 > identifiers. There=20 > > was some dispute about whether this is a good assumnption=20 > or not. I, and=20 > > some others, do believe that in many enterprises, it is a good=20 > > assumption that obtaining a new enterprise identifier is not easy. >=20 > While agree that outside of walled-gardens your example is not very=20 > useful, I do think this is very useful when your applies-to=20 > is scoped to=20 > a domain. >=20 > This is not limited to enterprise deployments. It may be true=20 > that some=20 > providers give away identities for free, it is not the case=20 > that _all_=20 > providers do this. In fact, I think the whole argument that you don't=20 > need exceptions becauses identities are free is bogus. >=20 > >=20 > > A second point on exceptions. If an exception represents a=20 > list, and you=20 > > can't dereference that list, then you have to drop the=20 > entire permission=20 > > statement. This is to ensure privacy-safety, so that=20 > information is not=20 > > leaked under any failure condition. > >=20 > > Finally, it needs to be clarified that exceptions still result in=20 > > additive permissions. So, for example, if I have two=20 > staements like this: > >=20 > > > > example.com > > > > sip:sally@example.com > > > > > >=20 > > > >=20 > > and > >=20 > > > > example.com > > > > sip:bob@example.com > > > > > >=20 > > > >=20 > >=20 > >=20 > > That if EITHER Sally or Bob subscribes, they will be=20 > granted permission=20 > > to subscribe. Thats because, if Bob subscribes, the first policy=20 > > statement applies to him, resulting in his subscription=20 > being accepted.=20 > > If Sally subscribes, the second applies to her, and her=20 > subscription is=20 > > accepted. > >=20 > > If you try and make except clauses carry across permission=20 > statements,=20 > > you end up in a place where these statements are no longer=20 > additive, and=20 > > you are not privacy safe anymore. > >=20 > > Now, even given these clarifications, the geopriv group is=20 > not planning=20 > > on specifying an except condition at this time. Though they=20 > consider it=20 > > useful, its been ruled out of scope for the initial policy=20 > document.=20 > > Thus, if we wish to align, we would need to also rule it=20 > out of scope in=20 > > the initial version of the specification. > >=20 > > That does not mean it could never be done; indeed, it would be my=20 > > proposal to more or less immediately have a draft defining it, and=20 > > progress this just behind the main specs. > >=20 > > IMHO, it is worth getting alignment to let this feature=20 > move forward in=20 > > a separate specification, behind the main one. > >=20 > > Comments and thoughts? >=20 > I personally do not think we can live without exceptions, even for a=20 > little while. Since the additive approach does not allow me to=20 > explicitly black-list someone and have that override any other=20 > permissions, then the only way I could create a rule that allowed=20 > everyone from example.com except alice would be to list every single=20 > member of example.com explicitly. This is bad enough from a=20 > convenience=20 > perspective--but in reality it is very unlikely example.com=20 > will share=20 > its membership roster with me, so I could not do this even if=20 > I wanted to. The way it works today is that you have a list of presentities and a = list of watchers. The list of watchers is what the issues are about. In = most systems today, the list of watchers is a mirror to the list of = presentities, and therefore does not include everyone is a domain.=20 I think it is ok for now to give permissions to individual watchers as = selected by the presentity. We are not at a stage in presence systems = where we want to allow everyone at a domain to view someone's presence = excepting individual x and y. But more like 15 to 20 individuals that = the presentity mostly interacts with in that domain. So, instead of allowing, for example, everyone at example.com except for = Bob. I can pick john, alice, ben and adam from example.com that I = interact with and want to allow to be my watchers, and create = permissions for them. This leaves out bob along with everyone else at = example.com. I think this is good enough. Regards, Hisham >=20 > I am willing to live with limiting exceptions expressions to=20 > things that=20 > never require external resolution. >=20 > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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-admin@ietf.org Tue Nov 25 03:21:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08108; Tue, 25 Nov 2003 03:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYRy-00000H-00; Tue, 25 Nov 2003 03:21:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOYRy-0007nr-00; Tue, 25 Nov 2003 03:21:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYRS-0003OW-JG; Tue, 25 Nov 2003 03:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYQe-0003Ne-CM for simple@optimus.ietf.org; Tue, 25 Nov 2003 03:20:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08085 for ; Tue, 25 Nov 2003 03:19:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYQc-0007nQ-00 for simple@ietf.org; Tue, 25 Nov 2003 03:20:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOYQb-0007nM-00 for simple@ietf.org; Tue, 25 Nov 2003 03:20:09 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP8K3609229 for ; Tue, 25 Nov 2003 10:20:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 10:19:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 10:19:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797432@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOyzgYxw05NIJMvQWKCSM/HvTzjQQAXqJkg To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 08:19:58.0350 (UTC) FILETIME=[EA1232E0:01C3B32C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 10:19:57 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 24.November.2003 23:00 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Can the user at least have a say in accepting or rejecting=20 > the subscription based on the availability of any=20 > authentication type. Eg: A user can reject subscriptions that=20 > are not authenticated in any way and accept subscriptions=20 > that are authenticated, regardless of authentication type. >=20 > In the absence of _some_ authentication, what is the value of having=20 > authorization policies in the first place? They have no=20 > meaning if you=20 > cannot put some degree of trust in the requestor identity. >=20 > I think the email world has proven to us how useful it is to=20 > authorize=20 > on un-authenticated headers. How useful is a spam filter that=20 > relies on=20 > the From header? Either I'm missing your point, or you missed mine. All I said was that = the user should be able to reject subscriptions if they are not = authenticated (authentication method is irrelevant). /Hisham >=20 > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Jonathan Rosenberg > >>Sent: 24.November.2003 08:13 > >>To: Simple WG > >>Subject: [Simple] xcap/geopriv alignment issue 4: authentication > >> > >> > >>Folks, > >> > >>Currently, xcap-auth defines an authentication condition.=20 > This allows=20 > >>you to decide whether to accept or reject a subscription=20 > based on the=20 > >>type of authentication used in the SUBSCRIBE request. > >> > >>The geopriv policy specification currently has no such mechanism. > >> > >>This was discussed during the geopriv meeting in=20 > Minneapolis. If you=20 > >>think about it for a bit, its not clear how this would actually get=20 > >>used. Remember, it is end users that will set these policies. What=20 > >>kind of meaningful information can be provided to a user about the=20 > >>differences between p-asserted-id and sip-identity and digest=20 > >>authentication? What would make a user give permission for=20 > >>one type or=20 > >>authentication, and not another? Practically speaking, it=20 > doesnt seem=20 > >>like its easy to use at all. > >> > >>As a result, I would propose to remove the authentication condition=20 > >>from xcap-auth. > >> > >>Comments? > >> > >>-Jonathan R. > >>--=20 > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > >>dynamicsoft > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 03:21:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08163 for ; Tue, 25 Nov 2003 03:21:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYS3-0003TH-2A for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 03:21:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP8LcLk013340 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 03:21:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYS2-0003T5-6T for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 03:21:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08108; Tue, 25 Nov 2003 03:21:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYRy-00000H-00; Tue, 25 Nov 2003 03:21:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOYRy-0007nr-00; Tue, 25 Nov 2003 03:21:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYRS-0003OW-JG; Tue, 25 Nov 2003 03:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOYQe-0003Ne-CM for simple@optimus.ietf.org; Tue, 25 Nov 2003 03:20:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08085 for ; Tue, 25 Nov 2003 03:19:59 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOYQc-0007nQ-00 for simple@ietf.org; Tue, 25 Nov 2003 03:20:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOYQb-0007nM-00 for simple@ietf.org; Tue, 25 Nov 2003 03:20:09 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP8K3609229 for ; Tue, 25 Nov 2003 10:20:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 10:19:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 10:19:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797432@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOyzgYxw05NIJMvQWKCSM/HvTzjQQAXqJkg To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 08:19:58.0350 (UTC) FILETIME=[EA1232E0:01C3B32C] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 10:19:57 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 24.November.2003 23:00 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Can the user at least have a say in accepting or rejecting=20 > the subscription based on the availability of any=20 > authentication type. Eg: A user can reject subscriptions that=20 > are not authenticated in any way and accept subscriptions=20 > that are authenticated, regardless of authentication type. >=20 > In the absence of _some_ authentication, what is the value of having=20 > authorization policies in the first place? They have no=20 > meaning if you=20 > cannot put some degree of trust in the requestor identity. >=20 > I think the email world has proven to us how useful it is to=20 > authorize=20 > on un-authenticated headers. How useful is a spam filter that=20 > relies on=20 > the From header? Either I'm missing your point, or you missed mine. All I said was that = the user should be able to reject subscriptions if they are not = authenticated (authentication method is irrelevant). /Hisham >=20 > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Jonathan Rosenberg > >>Sent: 24.November.2003 08:13 > >>To: Simple WG > >>Subject: [Simple] xcap/geopriv alignment issue 4: authentication > >> > >> > >>Folks, > >> > >>Currently, xcap-auth defines an authentication condition.=20 > This allows=20 > >>you to decide whether to accept or reject a subscription=20 > based on the=20 > >>type of authentication used in the SUBSCRIBE request. > >> > >>The geopriv policy specification currently has no such mechanism. > >> > >>This was discussed during the geopriv meeting in=20 > Minneapolis. If you=20 > >>think about it for a bit, its not clear how this would actually get=20 > >>used. Remember, it is end users that will set these policies. What=20 > >>kind of meaningful information can be provided to a user about the=20 > >>differences between p-asserted-id and sip-identity and digest=20 > >>authentication? What would make a user give permission for=20 > >>one type or=20 > >>authentication, and not another? Practically speaking, it=20 > doesnt seem=20 > >>like its easy to use at all. > >> > >>As a result, I would propose to remove the authentication condition=20 > >>from xcap-auth. > >> > >>Comments? > >> > >>-Jonathan R. > >>--=20 > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >>Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > >>dynamicsoft > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >>http://www.jdrosen.net PHONE: (973) 952-5000 > >>http://www.dynamicsoft.com > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 04:42:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10136; Tue, 25 Nov 2003 04:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZi9-0000wh-00; Tue, 25 Nov 2003 04:42:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZi8-0000we-00; Tue, 25 Nov 2003 04:42:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZhr-0006ce-83; Tue, 25 Nov 2003 04:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZh4-0006aM-Md for simple@optimus.ietf.org; Tue, 25 Nov 2003 04:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10081 for ; Tue, 25 Nov 2003 04:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZgz-0000w9-00 for simple@ietf.org; Tue, 25 Nov 2003 04:41:09 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOZgy-0000w6-00 for simple@ietf.org; Tue, 25 Nov 2003 04:41:08 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAP9f6Ss026070; Tue, 25 Nov 2003 10:41:06 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSX2GA30; Tue, 25 Nov 2003 10:41:06 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF1D918AC0; Tue, 25 Nov 2003 11:41:05 +0200 (EET) Message-ID: <3FC323B1.9050709@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell Cc: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> <3FC262B4.5040802@ericsson.com> <3FC26428.8040702@dynamicsoft.com> In-Reply-To: <3FC26428.8040702@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 11:41:05 +0200 Content-Transfer-Encoding: 7bit Inline. Ben Campbell wrote: > Miguel A. Garcia wrote: > >> I don't think I really agree. An endpoint that is configured to use a >> relay needs to know that it has to start the session by getting the >> MSRP URI from the relay itself, with a BIND primitive. Then it needs >> to know that the URI it got is the one he populates in the SDP. > > > That is exactly the knowledge I was talking about. Additionally, it has > to know that relays are even possible to start out with, which implies > knowledge of the relay specification. The relays that are possible are not dependent on the use of BIND. It is just a matter of configuration, it does not affect the procedures. The UE will send a BIND in the same manner to the relay, providing that it knows (configured with) the relay address. > > My understanding of the mandate to remove relays from the base spec is > that an endpoint that implements the base spec, and not the relay > extension, does not know that relays even exist. Furthermore, until we > complete the relay specification, we cannot know exactly how BIND should > work. I don't think we can put a constraint on the relay specification > that prevents it from changing the way you request a relay. Maybe I have a missunderstanding here, but as far as I understand from the SIMPLE minutes, the problem with relays lies in the relay-to-relay communication, because if the issues already discussed in the list with multiplexing and head of line blocking. As far as I understand, the problem does not affect the endpoint-to-relay session (does it?). What I am trying to avoid is that there are implementations of MSRP that will not support relays. It would be similar to not describing proxies in RFC 2616, and therefore, having web browsers that do not support proxies. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 04:42:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10178 for ; Tue, 25 Nov 2003 04:42:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZiE-0006io-17 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 04:42:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP9gPSp025832 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 04:42:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZiC-0006iZ-Oy for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 04:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10136; Tue, 25 Nov 2003 04:42:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZi9-0000wh-00; Tue, 25 Nov 2003 04:42:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZi8-0000we-00; Tue, 25 Nov 2003 04:42:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZhr-0006ce-83; Tue, 25 Nov 2003 04:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZh4-0006aM-Md for simple@optimus.ietf.org; Tue, 25 Nov 2003 04:41:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10081 for ; Tue, 25 Nov 2003 04:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZgz-0000w9-00 for simple@ietf.org; Tue, 25 Nov 2003 04:41:09 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOZgy-0000w6-00 for simple@ietf.org; Tue, 25 Nov 2003 04:41:08 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAP9f6Ss026070; Tue, 25 Nov 2003 10:41:06 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSX2GA30; Tue, 25 Nov 2003 10:41:06 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF1D918AC0; Tue, 25 Nov 2003 11:41:05 +0200 (EET) Message-ID: <3FC323B1.9050709@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell Cc: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> <3FC262B4.5040802@ericsson.com> <3FC26428.8040702@dynamicsoft.com> In-Reply-To: <3FC26428.8040702@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 11:41:05 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Inline. Ben Campbell wrote: > Miguel A. Garcia wrote: > >> I don't think I really agree. An endpoint that is configured to use a >> relay needs to know that it has to start the session by getting the >> MSRP URI from the relay itself, with a BIND primitive. Then it needs >> to know that the URI it got is the one he populates in the SDP. > > > That is exactly the knowledge I was talking about. Additionally, it has > to know that relays are even possible to start out with, which implies > knowledge of the relay specification. The relays that are possible are not dependent on the use of BIND. It is just a matter of configuration, it does not affect the procedures. The UE will send a BIND in the same manner to the relay, providing that it knows (configured with) the relay address. > > My understanding of the mandate to remove relays from the base spec is > that an endpoint that implements the base spec, and not the relay > extension, does not know that relays even exist. Furthermore, until we > complete the relay specification, we cannot know exactly how BIND should > work. I don't think we can put a constraint on the relay specification > that prevents it from changing the way you request a relay. Maybe I have a missunderstanding here, but as far as I understand from the SIMPLE minutes, the problem with relays lies in the relay-to-relay communication, because if the issues already discussed in the list with multiplexing and head of line blocking. As far as I understand, the problem does not affect the endpoint-to-relay session (does it?). What I am trying to avoid is that there are implementations of MSRP that will not support relays. It would be similar to not describing proxies in RFC 2616, and therefore, having web browsers that do not support proxies. /Miguel -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 04:42:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10200; Tue, 25 Nov 2003 04:42:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZio-0000xi-00; Tue, 25 Nov 2003 04:43:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZio-0000xc-00; Tue, 25 Nov 2003 04:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZip-0006oW-FS; Tue, 25 Nov 2003 04:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZih-0006m2-JZ for simple@optimus.ietf.org; Tue, 25 Nov 2003 04:42:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10174 for ; Tue, 25 Nov 2003 04:42:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZib-0000xR-00 for simple@ietf.org; Tue, 25 Nov 2003 04:42:49 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOZib-0000xO-00 for simple@ietf.org; Tue, 25 Nov 2003 04:42:49 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAP9gkSv026449; Tue, 25 Nov 2003 10:42:47 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSX2GB9D; Tue, 25 Nov 2003 10:42:43 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8D57718AC0; Tue, 25 Nov 2003 11:42:36 +0200 (EET) Message-ID: <3FC3240C.1050403@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB70118B108@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B108@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 11:42:36 +0200 Content-Transfer-Encoding: 7bit This proposal is an incomplete specification. Precluding support for proxies and NAT these days seems a bad idea. If you allow to have a collection of endpoints deployed that do not support relays, we will definitely get problems. /Miguel hisham.khartabil@nokia.com wrote: > Hi Miguel, > > I don't agree with you. The relay case will be seen as an extension of MS(R)P and therefore all methods to support relays should be defined in that document. > > If endpoint implementers want to support relays for NAT traversal, then they better implement whatever is documented in the relay document. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Miguel A. Garcia >>Sent: 24.November.2003 20:48 >>To: Ben Campbell >>Cc: Simple WG >>Subject: [Simple] BIND and relays documentation >> >> >>Hi: >> >>A question about the recent decision to split the MSRP >>protocol into a >>relay-less document and a document that details the use of relays. >> >>I would like to understand if the idea is to document the >>BIND primitive >>in the relay-less document or in the relayful document. >> >>Some folks may argue that the BIND primitive is only used in the case >>there are relays in the path, and as such, it should be documented in >>the relays document. However, in doing so, we may risk that >>end points >>will not implement the BIND primitive ever, and therefore will not >>support the operation through relays. >> >>I am in favour of documenting the BIND primitive in the core MSRP >>document, in spite that the relay operation will be described in the >>relays document. >> >>Is this something that the working group is thinking? >> >>/Miguel >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 04:52:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10365; Tue, 25 Nov 2003 04:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZsZ-00014J-00; Tue, 25 Nov 2003 04:53:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOZsY-00014G-00; Tue, 25 Nov 2003 04:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZsV-00072q-4F; Tue, 25 Nov 2003 04:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOZrm-00072L-Dm for simple@optimus.ietf.org; Tue, 25 Nov 2003 04:52:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10347 for ; Tue, 25 Nov 2003 04:52:03 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOZrj-00013V-00 for simple@ietf.org; Tue, 25 Nov 2003 04:52:15 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOZri-00013S-00 for simple@ietf.org; Tue, 25 Nov 2003 04:52:14 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAP9qD606594 for ; Tue, 25 Nov 2003 11:52:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 11:52:13 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 11:52:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzOIoS8zG/ubdPQ5SFxKEv6gJyuwAAPvFw To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 09:52:13.0740 (UTC) FILETIME=[CD6BAEC0:01C3B339] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 11:52:13 +0200 Content-Transfer-Encoding: quoted-printable We will support relays for NAT traversal, in a separate document. But = having half the solution documented is a separate I-D is not = appropriate, IMO. /Hisham > -----Original Message----- > From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > Sent: 25.November.2003 11:43 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] BIND and relays documentation >=20 >=20 > This proposal is an incomplete specification. Precluding support for=20 > proxies and NAT these days seems a bad idea. If you allow to have a=20 > collection of endpoints deployed that do not support relays, we will=20 > definitely get problems. >=20 > /Miguel >=20 > hisham.khartabil@nokia.com wrote: >=20 > > Hi Miguel, > >=20 > > I don't agree with you. The relay case will be seen as an=20 > extension of MS(R)P and therefore all methods to support=20 > relays should be defined in that document. > >=20 > > If endpoint implementers want to support relays for NAT=20 > traversal, then they better implement whatever is documented=20 > in the relay document. > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Miguel A. Garcia > >>Sent: 24.November.2003 20:48 > >>To: Ben Campbell > >>Cc: Simple WG > >>Subject: [Simple] BIND and relays documentation > >> > >> > >>Hi: > >> > >>A question about the recent decision to split the MSRP=20 > >>protocol into a=20 > >>relay-less document and a document that details the use of relays. > >> > >>I would like to understand if the idea is to document the=20 > >>BIND primitive=20 > >>in the relay-less document or in the relayful document. > >> > >>Some folks may argue that the BIND primitive is only used=20 > in the case=20 > >>there are relays in the path, and as such, it should be=20 > documented in=20 > >>the relays document. However, in doing so, we may risk that=20 > >>end points=20 > >>will not implement the BIND primitive ever, and therefore will not=20 > >>support the operation through relays. > >> > >>I am in favour of documenting the BIND primitive in the core MSRP=20 > >>document, in spite that the relay operation will be=20 > described in the=20 > >>relays document. > >> > >>Is this something that the working group is thinking? > >> > >>/Miguel > >>--=20 > >>Miguel-Angel Garcia Oy LM Ericsson AB > >> Jorvas, Finland > >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 06:46:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13951; Tue, 25 Nov 2003 06:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOben-0002dt-00; Tue, 25 Nov 2003 06:47:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOben-0002dq-00; Tue, 25 Nov 2003 06:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObeo-0003hL-Cr; Tue, 25 Nov 2003 06:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObeI-0003gv-2A for simple@optimus.ietf.org; Tue, 25 Nov 2003 06:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13915 for ; Tue, 25 Nov 2003 06:46:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObeD-0002bV-00 for simple@ietf.org; Tue, 25 Nov 2003 06:46:25 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AObeD-0002bQ-00 for simple@ietf.org; Tue, 25 Nov 2003 06:46:25 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPBkOI3013143; Tue, 25 Nov 2003 12:46:24 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSYD71QN; Tue, 25 Nov 2003 12:46:24 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BFDD118A82; Tue, 25 Nov 2003 13:46:18 +0200 (EET) Message-ID: <3FC3410A.7080803@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:46:18 +0200 Content-Transfer-Encoding: 7bit To me the "half" solution is to document the interaction between the endpoint and the relays in a different document. This sounds a lame solution comparable to not supporting proxies in RFC 3261 or RFC 2616. /Miguel hisham.khartabil@nokia.com wrote: > We will support relays for NAT traversal, in a separate document. But having half the solution documented is a separate I-D is not appropriate, IMO. > > /Hisham > > >>-----Original Message----- >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: 25.November.2003 11:43 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >> >>This proposal is an incomplete specification. Precluding support for >>proxies and NAT these days seems a bad idea. If you allow to have a >>collection of endpoints deployed that do not support relays, we will >>definitely get problems. >> >>/Miguel >> >>hisham.khartabil@nokia.com wrote: >> >> >>>Hi Miguel, >>> >>>I don't agree with you. The relay case will be seen as an >> >>extension of MS(R)P and therefore all methods to support >>relays should be defined in that document. >> >>>If endpoint implementers want to support relays for NAT >> >>traversal, then they better implement whatever is documented >>in the relay document. >> >>>Regards, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Miguel A. Garcia >>>>Sent: 24.November.2003 20:48 >>>>To: Ben Campbell >>>>Cc: Simple WG >>>>Subject: [Simple] BIND and relays documentation >>>> >>>> >>>>Hi: >>>> >>>>A question about the recent decision to split the MSRP >>>>protocol into a >>>>relay-less document and a document that details the use of relays. >>>> >>>>I would like to understand if the idea is to document the >>>>BIND primitive >>>>in the relay-less document or in the relayful document. >>>> >>>>Some folks may argue that the BIND primitive is only used >> >>in the case >> >>>>there are relays in the path, and as such, it should be >> >>documented in >> >>>>the relays document. However, in doing so, we may risk that >>>>end points >>>>will not implement the BIND primitive ever, and therefore will not >>>>support the operation through relays. >>>> >>>>I am in favour of documenting the BIND primitive in the core MSRP >>>>document, in spite that the relay operation will be >> >>described in the >> >>>>relays document. >>>> >>>>Is this something that the working group is thinking? >>>> >>>>/Miguel >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 06:47:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13971 for ; Tue, 25 Nov 2003 06:47:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObes-0003iB-9X for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 06:47:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBl6tt014267 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 06:47:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObes-0003i2-5r for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13951; Tue, 25 Nov 2003 06:46:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOben-0002dt-00; Tue, 25 Nov 2003 06:47:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOben-0002dq-00; Tue, 25 Nov 2003 06:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObeo-0003hL-Cr; Tue, 25 Nov 2003 06:47:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObeI-0003gv-2A for simple@optimus.ietf.org; Tue, 25 Nov 2003 06:46:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13915 for ; Tue, 25 Nov 2003 06:46:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObeD-0002bV-00 for simple@ietf.org; Tue, 25 Nov 2003 06:46:25 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AObeD-0002bQ-00 for simple@ietf.org; Tue, 25 Nov 2003 06:46:25 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPBkOI3013143; Tue, 25 Nov 2003 12:46:24 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSYD71QN; Tue, 25 Nov 2003 12:46:24 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BFDD118A82; Tue, 25 Nov 2003 13:46:18 +0200 (EET) Message-ID: <3FC3410A.7080803@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: hisham.khartabil@nokia.com Cc: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:46:18 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To me the "half" solution is to document the interaction between the endpoint and the relays in a different document. This sounds a lame solution comparable to not supporting proxies in RFC 3261 or RFC 2616. /Miguel hisham.khartabil@nokia.com wrote: > We will support relays for NAT traversal, in a separate document. But having half the solution documented is a separate I-D is not appropriate, IMO. > > /Hisham > > >>-----Original Message----- >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: 25.November.2003 11:43 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >> >>This proposal is an incomplete specification. Precluding support for >>proxies and NAT these days seems a bad idea. If you allow to have a >>collection of endpoints deployed that do not support relays, we will >>definitely get problems. >> >>/Miguel >> >>hisham.khartabil@nokia.com wrote: >> >> >>>Hi Miguel, >>> >>>I don't agree with you. The relay case will be seen as an >> >>extension of MS(R)P and therefore all methods to support >>relays should be defined in that document. >> >>>If endpoint implementers want to support relays for NAT >> >>traversal, then they better implement whatever is documented >>in the relay document. >> >>>Regards, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Miguel A. Garcia >>>>Sent: 24.November.2003 20:48 >>>>To: Ben Campbell >>>>Cc: Simple WG >>>>Subject: [Simple] BIND and relays documentation >>>> >>>> >>>>Hi: >>>> >>>>A question about the recent decision to split the MSRP >>>>protocol into a >>>>relay-less document and a document that details the use of relays. >>>> >>>>I would like to understand if the idea is to document the >>>>BIND primitive >>>>in the relay-less document or in the relayful document. >>>> >>>>Some folks may argue that the BIND primitive is only used >> >>in the case >> >>>>there are relays in the path, and as such, it should be >> >>documented in >> >>>>the relays document. However, in doing so, we may risk that >>>>end points >>>>will not implement the BIND primitive ever, and therefore will not >>>>support the operation through relays. >>>> >>>>I am in favour of documenting the BIND primitive in the core MSRP >>>>document, in spite that the relay operation will be >> >>described in the >> >>>>relays document. >>>> >>>>Is this something that the working group is thinking? >>>> >>>>/Miguel >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> > > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 06:58:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14421; Tue, 25 Nov 2003 06:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObqR-0002v9-00; Tue, 25 Nov 2003 06:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObqQ-0002v6-00; Tue, 25 Nov 2003 06:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObqO-0004Lr-S2; Tue, 25 Nov 2003 06:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObpZ-0004D7-7t for simple@optimus.ietf.org; Tue, 25 Nov 2003 06:58:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14374 for ; Tue, 25 Nov 2003 06:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObpU-0002ts-00 for simple@ietf.org; Tue, 25 Nov 2003 06:58:04 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1AObpU-0002tA-00 for simple@ietf.org; Tue, 25 Nov 2003 06:58:04 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-4.tower-49.messagelabs.com!1069761441!440750 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 32628 invoked from network); 25 Nov 2003 11:57:21 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-4.tower-49.messagelabs.com with SMTP; 25 Nov 2003 11:57:21 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Tue, 25 Nov 2003 11:59:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] BIND and relays documentation Message-ID: <45730E094814E44488F789C1CDED27AE0219B120@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzSdhSXR8/Cz0wSpSf4yIuCwu8EAAADmOg From: "Chris Boulton" To: "Miguel A. Garcia" , Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 11:56:53 -0000 Content-Transfer-Encoding: quoted-printable I=20personally=20don't=20see=20a=20problem=20having=20an=20MS(R)P=20client= =20that=20is=20not 'relay'=20aware,=20as=20long=20as=20the=20two=20documents=20are=20tightly=20= coupled=20and referenced=20appropriately.=20=20As=20long=20as=20implementers=20know=20ca= tegorically that=20for=20their=20client=20to=20work=20with=20Relays,=20they=20must=20i= mplement=20reference x. Chris. =20=20 >-----Original=20Message----- >From:=20Miguel=20A.=20Garcia=20[mailto:Miguel.A.Garcia@ericsson.com] >Sent:=2025=20November=202003=2011:46 >To:=20hisham.khartabil@nokia.com >Cc:=20bcampbell@dynamicsoft.com;=20simple@ietf.org >Subject:=20Re:=20[Simple]=20BIND=20and=20relays=20documentation > >To=20me=20the=20"half"=20solution=20is=20to=20document=20the=20interactio= n=20between=20the >endpoint=20and=20the=20relays=20in=20a=20different=20document.=20This=20s= ounds=20a=20lame >solution=20comparable=20to=20not=20supporting=20proxies=20in=20RFC=203261= =20or=20RFC=202616. > >/Miguel > >hisham.khartabil@nokia.com=20wrote: > >>=20We=20will=20support=20relays=20for=20NAT=20traversal,=20in=20a=20sepa= rate=20document.=20But >having=20half=20the=20solution=20documented=20is=20a=20separate=20I-D=20i= s=20not appropriate, >IMO. >> >>=20/Hisham >> >> >>>-----Original=20Message----- >>>From:=20ext=20Miguel=20A.=20Garcia=20[mailto:Miguel.A.Garcia@ericsson.c= om] >>>Sent:=2025.November.2003=2011:43 >>>To:=20Khartabil=20Hisham=20(NMP-MSW/Helsinki) >>>Cc:=20bcampbell@dynamicsoft.com;=20simple@ietf.org >>>Subject:=20Re:=20[Simple]=20BIND=20and=20relays=20documentation >>> >>> >>>This=20proposal=20is=20an=20incomplete=20specification.=20Precluding=20= support=20for >>>proxies=20and=20NAT=20these=20days=20seems=20a=20bad=20idea.=20If=20you= =20allow=20to=20have=20a >>>collection=20of=20endpoints=20deployed=20that=20do=20not=20support=20re= lays,=20we=20will >>>definitely=20get=20problems. >>> >>>/Miguel >>> >>>hisham.khartabil@nokia.com=20wrote: >>> >>> >>>>Hi=20Miguel, >>>> >>>>I=20don't=20agree=20with=20you.=20The=20relay=20case=20will=20be=20see= n=20as=20an >>> >>>extension=20of=20MS(R)P=20and=20therefore=20all=20methods=20to=20suppor= t >>>relays=20should=20be=20defined=20in=20that=20document. >>> >>>>If=20endpoint=20implementers=20want=20to=20support=20relays=20for=20NA= T >>> >>>traversal,=20then=20they=20better=20implement=20whatever=20is=20documen= ted >>>in=20the=20relay=20document. >>> >>>>Regards, >>>>Hisham >>>> >>>> >>>> >>>>>-----Original=20Message----- >>>>>From:=20simple-admin@ietf.org >>> >>>[mailto:simple-admin@ietf.org]On=20Behalf=20Of >>> >>>>>ext=20Miguel=20A.=20Garcia >>>>>Sent:=2024.November.2003=2020:48 >>>>>To:=20Ben=20Campbell >>>>>Cc:=20Simple=20WG >>>>>Subject:=20[Simple]=20BIND=20and=20relays=20documentation >>>>> >>>>> >>>>>Hi: >>>>> >>>>>A=20question=20about=20the=20recent=20decision=20to=20split=20the=20M= SRP >>>>>protocol=20into=20a >>>>>relay-less=20document=20and=20a=20document=20that=20details=20the=20u= se=20of=20relays. >>>>> >>>>>I=20would=20like=20to=20understand=20if=20the=20idea=20is=20to=20docu= ment=20the >>>>>BIND=20primitive >>>>>in=20the=20relay-less=20document=20or=20in=20the=20relayful=20documen= t. >>>>> >>>>>Some=20folks=20may=20argue=20that=20the=20BIND=20primitive=20is=20onl= y=20used >>> >>>in=20the=20case >>> >>>>>there=20are=20relays=20in=20the=20path,=20and=20as=20such,=20it=20sho= uld=20be >>> >>>documented=20in >>> >>>>>the=20relays=20document.=20However,=20in=20doing=20so,=20we=20may=20r= isk=20that >>>>>end=20points >>>>>will=20not=20implement=20the=20BIND=20primitive=20ever,=20and=20there= fore=20will=20not >>>>>support=20the=20operation=20through=20relays. >>>>> >>>>>I=20am=20in=20favour=20of=20documenting=20the=20BIND=20primitive=20in= =20the=20core=20MSRP >>>>>document,=20in=20spite=20that=20the=20relay=20operation=20will=20be >>> >>>described=20in=20the >>> >>>>>relays=20document. >>>>> >>>>>Is=20this=20something=20that=20the=20working=20group=20is=20thinking?= >>>>> >>>>>/Miguel >>>>>-- >>>>>Miguel-Angel=20Garcia=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Oy=20LM=20Ericsson=20AB >>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Jorvas,=20Finland >>>>>mailto:Miguel.A.Garcia@ericsson.com=20=20=20=20=20Phone:=20=20+358=20= 9=20299=203553 >>>>>mailto:Miguel.A.Garcia@piuha.net=20=20=20=20=20=20=20=20Mobile:=20+35= 8=2040=20514=200002 >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple=20mailing=20list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>-- >>>Miguel-Angel=20Garcia=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20Oy=20LM=20Ericsson=20AB >>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Jorvas,=20Finland >>>mailto:Miguel.A.Garcia@ericsson.com=20=20=20=20=20Phone:=20=20+358=209=20= 299=203553 >>>mailto:Miguel.A.Garcia@piuha.net=20=20=20=20=20=20=20=20Mobile:=20+358=20= 40=20514=200002 >>> >> >> > >-- >Miguel-Angel=20Garcia=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Oy=20LM=20Ericsson=20AB >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Jorvas,=20Finland >mailto:Miguel.A.Garcia@ericsson.com=20=20=20=20=20Phone:=20=20+358=209=20= 299=203553 >mailto:Miguel.A.Garcia@piuha.net=20=20=20=20=20=20=20=20Mobile:=20+358=20= 40=20514=200002 > > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 06:59:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14441 for ; Tue, 25 Nov 2003 06:59:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObqW-0004Ow-8E for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 06:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBx8mG016912 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 06:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObqW-0004Oh-3g for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 06:59:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14421; Tue, 25 Nov 2003 06:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObqR-0002v9-00; Tue, 25 Nov 2003 06:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AObqQ-0002v6-00; Tue, 25 Nov 2003 06:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObqO-0004Lr-S2; Tue, 25 Nov 2003 06:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObpZ-0004D7-7t for simple@optimus.ietf.org; Tue, 25 Nov 2003 06:58:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14374 for ; Tue, 25 Nov 2003 06:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AObpU-0002ts-00 for simple@ietf.org; Tue, 25 Nov 2003 06:58:04 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1AObpU-0002tA-00 for simple@ietf.org; Tue, 25 Nov 2003 06:58:04 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-4.tower-49.messagelabs.com!1069761441!440750 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 32628 invoked from network); 25 Nov 2003 11:57:21 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-4.tower-49.messagelabs.com with SMTP; 25 Nov 2003 11:57:21 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Tue, 25 Nov 2003 11:59:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] BIND and relays documentation Message-ID: <45730E094814E44488F789C1CDED27AE0219B120@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzSdhSXR8/Cz0wSpSf4yIuCwu8EAAADmOg From: "Chris Boulton" To: "Miguel A. Garcia" , Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 11:56:53 -0000 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I=20personally=20don't=20see=20a=20problem=20having=20an=20MS(R)P=20client= =20that=20is=20not 'relay'=20aware,=20as=20long=20as=20the=20two=20documents=20are=20tightly=20= coupled=20and referenced=20appropriately.=20=20As=20long=20as=20implementers=20know=20ca= tegorically that=20for=20their=20client=20to=20work=20with=20Relays,=20they=20must=20i= mplement=20reference x. Chris. =20=20 >-----Original=20Message----- >From:=20Miguel=20A.=20Garcia=20[mailto:Miguel.A.Garcia@ericsson.com] >Sent:=2025=20November=202003=2011:46 >To:=20hisham.khartabil@nokia.com >Cc:=20bcampbell@dynamicsoft.com;=20simple@ietf.org >Subject:=20Re:=20[Simple]=20BIND=20and=20relays=20documentation > >To=20me=20the=20"half"=20solution=20is=20to=20document=20the=20interactio= n=20between=20the >endpoint=20and=20the=20relays=20in=20a=20different=20document.=20This=20s= ounds=20a=20lame >solution=20comparable=20to=20not=20supporting=20proxies=20in=20RFC=203261= =20or=20RFC=202616. > >/Miguel > >hisham.khartabil@nokia.com=20wrote: > >>=20We=20will=20support=20relays=20for=20NAT=20traversal,=20in=20a=20sepa= rate=20document.=20But >having=20half=20the=20solution=20documented=20is=20a=20separate=20I-D=20i= s=20not appropriate, >IMO. >> >>=20/Hisham >> >> >>>-----Original=20Message----- >>>From:=20ext=20Miguel=20A.=20Garcia=20[mailto:Miguel.A.Garcia@ericsson.c= om] >>>Sent:=2025.November.2003=2011:43 >>>To:=20Khartabil=20Hisham=20(NMP-MSW/Helsinki) >>>Cc:=20bcampbell@dynamicsoft.com;=20simple@ietf.org >>>Subject:=20Re:=20[Simple]=20BIND=20and=20relays=20documentation >>> >>> >>>This=20proposal=20is=20an=20incomplete=20specification.=20Precluding=20= support=20for >>>proxies=20and=20NAT=20these=20days=20seems=20a=20bad=20idea.=20If=20you= =20allow=20to=20have=20a >>>collection=20of=20endpoints=20deployed=20that=20do=20not=20support=20re= lays,=20we=20will >>>definitely=20get=20problems. >>> >>>/Miguel >>> >>>hisham.khartabil@nokia.com=20wrote: >>> >>> >>>>Hi=20Miguel, >>>> >>>>I=20don't=20agree=20with=20you.=20The=20relay=20case=20will=20be=20see= n=20as=20an >>> >>>extension=20of=20MS(R)P=20and=20therefore=20all=20methods=20to=20suppor= t >>>relays=20should=20be=20defined=20in=20that=20document. >>> >>>>If=20endpoint=20implementers=20want=20to=20support=20relays=20for=20NA= T >>> >>>traversal,=20then=20they=20better=20implement=20whatever=20is=20documen= ted >>>in=20the=20relay=20document. >>> >>>>Regards, >>>>Hisham >>>> >>>> >>>> >>>>>-----Original=20Message----- >>>>>From:=20simple-admin@ietf.org >>> >>>[mailto:simple-admin@ietf.org]On=20Behalf=20Of >>> >>>>>ext=20Miguel=20A.=20Garcia >>>>>Sent:=2024.November.2003=2020:48 >>>>>To:=20Ben=20Campbell >>>>>Cc:=20Simple=20WG >>>>>Subject:=20[Simple]=20BIND=20and=20relays=20documentation >>>>> >>>>> >>>>>Hi: >>>>> >>>>>A=20question=20about=20the=20recent=20decision=20to=20split=20the=20M= SRP >>>>>protocol=20into=20a >>>>>relay-less=20document=20and=20a=20document=20that=20details=20the=20u= se=20of=20relays. >>>>> >>>>>I=20would=20like=20to=20understand=20if=20the=20idea=20is=20to=20docu= ment=20the >>>>>BIND=20primitive >>>>>in=20the=20relay-less=20document=20or=20in=20the=20relayful=20documen= t. >>>>> >>>>>Some=20folks=20may=20argue=20that=20the=20BIND=20primitive=20is=20onl= y=20used >>> >>>in=20the=20case >>> >>>>>there=20are=20relays=20in=20the=20path,=20and=20as=20such,=20it=20sho= uld=20be >>> >>>documented=20in >>> >>>>>the=20relays=20document.=20However,=20in=20doing=20so,=20we=20may=20r= isk=20that >>>>>end=20points >>>>>will=20not=20implement=20the=20BIND=20primitive=20ever,=20and=20there= fore=20will=20not >>>>>support=20the=20operation=20through=20relays. >>>>> >>>>>I=20am=20in=20favour=20of=20documenting=20the=20BIND=20primitive=20in= =20the=20core=20MSRP >>>>>document,=20in=20spite=20that=20the=20relay=20operation=20will=20be >>> >>>described=20in=20the >>> >>>>>relays=20document. >>>>> >>>>>Is=20this=20something=20that=20the=20working=20group=20is=20thinking?= >>>>> >>>>>/Miguel >>>>>-- >>>>>Miguel-Angel=20Garcia=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20Oy=20LM=20Ericsson=20AB >>>>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Jorvas,=20Finland >>>>>mailto:Miguel.A.Garcia@ericsson.com=20=20=20=20=20Phone:=20=20+358=20= 9=20299=203553 >>>>>mailto:Miguel.A.Garcia@piuha.net=20=20=20=20=20=20=20=20Mobile:=20+35= 8=2040=20514=200002 >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Simple=20mailing=20list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>-- >>>Miguel-Angel=20Garcia=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20Oy=20LM=20Ericsson=20AB >>>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Jorvas,=20Finland >>>mailto:Miguel.A.Garcia@ericsson.com=20=20=20=20=20Phone:=20=20+358=209=20= 299=203553 >>>mailto:Miguel.A.Garcia@piuha.net=20=20=20=20=20=20=20=20Mobile:=20+358=20= 40=20514=200002 >>> >> >> > >-- >Miguel-Angel=20Garcia=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20Oy=20LM=20Ericsson=20AB >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20Jorvas,=20Finland >mailto:Miguel.A.Garcia@ericsson.com=20=20=20=20=20Phone:=20=20+358=209=20= 299=203553 >mailto:Miguel.A.Garcia@piuha.net=20=20=20=20=20=20=20=20Mobile:=20+358=20= 40=20514=200002 > > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 07:51:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15947; Tue, 25 Nov 2003 07:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcfn-0004Bx-00; Tue, 25 Nov 2003 07:52:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOcfm-0004Bu-00; Tue, 25 Nov 2003 07:52:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcfh-0006fr-5y; Tue, 25 Nov 2003 07:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcfe-0006fb-K1 for simple@optimus.ietf.org; Tue, 25 Nov 2003 07:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15944 for ; Tue, 25 Nov 2003 07:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcfd-0004Bo-00 for simple@ietf.org; Tue, 25 Nov 2003 07:51:57 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOcfd-0004Bh-00 for simple@ietf.org; Tue, 25 Nov 2003 07:51:57 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPCptV27706; Tue, 25 Nov 2003 13:51:55 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPCptm29376; Tue, 25 Nov 2003 13:51:55 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 13:51:37 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0478@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'hisham.khartabil@nokia.com'" , jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] xcap/geopriv alignment, issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:50:37 +0100 hi hisham, i fully agree with your proposal. identifying the parts which are common for geopriv and for xcap-authz makes sense to me. ciao hannes > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, November 24, 2003 12:50 PM > To: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment, issue > > > Since we are mirroring a lot of geopriv's schema; I have a suggestion: > > Why don't we define a common schema for both using one xml > namespace. It can have all the needed elements like > , , etc. > > xcap-auth specific elements can then be specified as > extensions defined. Geopriv can do the same with their > specific elements. > > Regards, > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 07:52:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15975 for ; Tue, 25 Nov 2003 07:52:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcfo-0006gm-Pk for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 07:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPCq88U025706 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 07:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcfo-0006gW-Kr for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 07:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15947; Tue, 25 Nov 2003 07:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcfn-0004Bx-00; Tue, 25 Nov 2003 07:52:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOcfm-0004Bu-00; Tue, 25 Nov 2003 07:52:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcfh-0006fr-5y; Tue, 25 Nov 2003 07:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOcfe-0006fb-K1 for simple@optimus.ietf.org; Tue, 25 Nov 2003 07:51:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15944 for ; Tue, 25 Nov 2003 07:51:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOcfd-0004Bo-00 for simple@ietf.org; Tue, 25 Nov 2003 07:51:57 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOcfd-0004Bh-00 for simple@ietf.org; Tue, 25 Nov 2003 07:51:57 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPCptV27706; Tue, 25 Nov 2003 13:51:55 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPCptm29376; Tue, 25 Nov 2003 13:51:55 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 13:51:37 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0478@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'hisham.khartabil@nokia.com'" , jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] xcap/geopriv alignment, issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:50:37 +0100 hi hisham, i fully agree with your proposal. identifying the parts which are common for geopriv and for xcap-authz makes sense to me. ciao hannes > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, November 24, 2003 12:50 PM > To: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment, issue > > > Since we are mirroring a lot of geopriv's schema; I have a suggestion: > > Why don't we define a common schema for both using one xml > namespace. It can have all the needed elements like > , , etc. > > xcap-auth specific elements can then be specified as > extensions defined. Geopriv can do the same with their > specific elements. > > Regards, > Hisham > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 08:50:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17376; Tue, 25 Nov 2003 08:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdas-0005GL-00; Tue, 25 Nov 2003 08:51:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdas-0005GI-00; Tue, 25 Nov 2003 08:51:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdao-0000jU-L4; Tue, 25 Nov 2003 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdaA-0000iT-PO for simple@optimus.ietf.org; Tue, 25 Nov 2003 08:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17358 for ; Tue, 25 Nov 2003 08:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOda9-0005Fs-00 for simple@ietf.org; Tue, 25 Nov 2003 08:50:21 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOda8-0005Fp-00 for simple@ietf.org; Tue, 25 Nov 2003 08:50:20 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPDoDSt029425; Tue, 25 Nov 2003 14:50:17 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSZ2A0FH; Tue, 25 Nov 2003 14:50:11 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 46B7818A82; Tue, 25 Nov 2003 15:50:10 +0200 (EET) Message-ID: <3FC35E11.8090808@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Chris Boulton Cc: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <45730E094814E44488F789C1CDED27AE0219B120@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B120@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 15:50:09 +0200 Content-Transfer-Encoding: 7bit Chris: I don't find a problem with this approach either. I was afraid that the MS(R)P client document will go ahead of the relays document. This hypothetical situation will allow to deploy clients that do not support relays, and this is what I am trying to avoid. At least, by reading the minutes of the meeting, I got the impression that the relays document has to solve certain aspects that may require some time to think and discuss. That is the reason why I proposed to have a first document that supports the BIND operation in the client, but does not specify how the relay-to-relay connection is done. /Miguel Chris Boulton wrote: > I personally don't see a problem having an MS(R)P client that is not > 'relay' aware, as long as the two documents are tightly coupled and > referenced appropriately. As long as implementers know categorically > that for their client to work with Relays, they must implement reference > x. > > Chris. > > > >>-----Original Message----- >>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: 25 November 2003 11:46 >>To: hisham.khartabil@nokia.com >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >>To me the "half" solution is to document the interaction between the >>endpoint and the relays in a different document. This sounds a lame >>solution comparable to not supporting proxies in RFC 3261 or RFC 2616. >> >>/Miguel >> >>hisham.khartabil@nokia.com wrote: >> >> >>>We will support relays for NAT traversal, in a separate document. But >> >>having half the solution documented is a separate I-D is not > > appropriate, > >>IMO. >> >>>/Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>Sent: 25.November.2003 11:43 >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>>>Subject: Re: [Simple] BIND and relays documentation >>>> >>>> >>>>This proposal is an incomplete specification. Precluding support for >>>>proxies and NAT these days seems a bad idea. If you allow to have a >>>>collection of endpoints deployed that do not support relays, we will >>>>definitely get problems. >>>> >>>>/Miguel >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>> >>>> >>>>>Hi Miguel, >>>>> >>>>>I don't agree with you. The relay case will be seen as an >>>> >>>>extension of MS(R)P and therefore all methods to support >>>>relays should be defined in that document. >>>> >>>> >>>>>If endpoint implementers want to support relays for NAT >>>> >>>>traversal, then they better implement whatever is documented >>>>in the relay document. >>>> >>>> >>>>>Regards, >>>>>Hisham >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org >>>> >>>>[mailto:simple-admin@ietf.org]On Behalf Of >>>> >>>> >>>>>>ext Miguel A. Garcia >>>>>>Sent: 24.November.2003 20:48 >>>>>>To: Ben Campbell >>>>>>Cc: Simple WG >>>>>>Subject: [Simple] BIND and relays documentation >>>>>> >>>>>> >>>>>>Hi: >>>>>> >>>>>>A question about the recent decision to split the MSRP >>>>>>protocol into a >>>>>>relay-less document and a document that details the use of relays. >>>>>> >>>>>>I would like to understand if the idea is to document the >>>>>>BIND primitive >>>>>>in the relay-less document or in the relayful document. >>>>>> >>>>>>Some folks may argue that the BIND primitive is only used >>>> >>>>in the case >>>> >>>> >>>>>>there are relays in the path, and as such, it should be >>>> >>>>documented in >>>> >>>> >>>>>>the relays document. However, in doing so, we may risk that >>>>>>end points >>>>>>will not implement the BIND primitive ever, and therefore will not >>>>>>support the operation through relays. >>>>>> >>>>>>I am in favour of documenting the BIND primitive in the core MSRP >>>>>>document, in spite that the relay operation will be >>>> >>>>described in the >>>> >>>> >>>>>>relays document. >>>>>> >>>>>>Is this something that the working group is thinking? >>>>>> >>>>>>/Miguel >>>>>>-- >>>>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>>>> Jorvas, Finland >>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>> >>> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >>_______________________________________________________________________ > > _ > >>This email has been scanned for all viruses by the MessageLabs Email >>Security System. For more information on a proactive email security >>service working around the clock, around the globe, visit >>http://www.messagelabs.com >>_______________________________________________________________________ > > _ > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ________________________________________________________________________ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 08:51:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17397 for ; Tue, 25 Nov 2003 08:51:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdau-0000ke-H5 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 08:51:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPDp8k8002873 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 08:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdau-0000kC-Bq for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 08:51:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17376; Tue, 25 Nov 2003 08:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdas-0005GL-00; Tue, 25 Nov 2003 08:51:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdas-0005GI-00; Tue, 25 Nov 2003 08:51:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdao-0000jU-L4; Tue, 25 Nov 2003 08:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdaA-0000iT-PO for simple@optimus.ietf.org; Tue, 25 Nov 2003 08:50:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17358 for ; Tue, 25 Nov 2003 08:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOda9-0005Fs-00 for simple@ietf.org; Tue, 25 Nov 2003 08:50:21 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOda8-0005Fp-00 for simple@ietf.org; Tue, 25 Nov 2003 08:50:20 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPDoDSt029425; Tue, 25 Nov 2003 14:50:17 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XSZ2A0FH; Tue, 25 Nov 2003 14:50:11 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 46B7818A82; Tue, 25 Nov 2003 15:50:10 +0200 (EET) Message-ID: <3FC35E11.8090808@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Chris Boulton Cc: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <45730E094814E44488F789C1CDED27AE0219B120@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B120@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 15:50:09 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Chris: I don't find a problem with this approach either. I was afraid that the MS(R)P client document will go ahead of the relays document. This hypothetical situation will allow to deploy clients that do not support relays, and this is what I am trying to avoid. At least, by reading the minutes of the meeting, I got the impression that the relays document has to solve certain aspects that may require some time to think and discuss. That is the reason why I proposed to have a first document that supports the BIND operation in the client, but does not specify how the relay-to-relay connection is done. /Miguel Chris Boulton wrote: > I personally don't see a problem having an MS(R)P client that is not > 'relay' aware, as long as the two documents are tightly coupled and > referenced appropriately. As long as implementers know categorically > that for their client to work with Relays, they must implement reference > x. > > Chris. > > > >>-----Original Message----- >>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: 25 November 2003 11:46 >>To: hisham.khartabil@nokia.com >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >>To me the "half" solution is to document the interaction between the >>endpoint and the relays in a different document. This sounds a lame >>solution comparable to not supporting proxies in RFC 3261 or RFC 2616. >> >>/Miguel >> >>hisham.khartabil@nokia.com wrote: >> >> >>>We will support relays for NAT traversal, in a separate document. But >> >>having half the solution documented is a separate I-D is not > > appropriate, > >>IMO. >> >>>/Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>Sent: 25.November.2003 11:43 >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>>>Subject: Re: [Simple] BIND and relays documentation >>>> >>>> >>>>This proposal is an incomplete specification. Precluding support for >>>>proxies and NAT these days seems a bad idea. If you allow to have a >>>>collection of endpoints deployed that do not support relays, we will >>>>definitely get problems. >>>> >>>>/Miguel >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>> >>>> >>>>>Hi Miguel, >>>>> >>>>>I don't agree with you. The relay case will be seen as an >>>> >>>>extension of MS(R)P and therefore all methods to support >>>>relays should be defined in that document. >>>> >>>> >>>>>If endpoint implementers want to support relays for NAT >>>> >>>>traversal, then they better implement whatever is documented >>>>in the relay document. >>>> >>>> >>>>>Regards, >>>>>Hisham >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: simple-admin@ietf.org >>>> >>>>[mailto:simple-admin@ietf.org]On Behalf Of >>>> >>>> >>>>>>ext Miguel A. Garcia >>>>>>Sent: 24.November.2003 20:48 >>>>>>To: Ben Campbell >>>>>>Cc: Simple WG >>>>>>Subject: [Simple] BIND and relays documentation >>>>>> >>>>>> >>>>>>Hi: >>>>>> >>>>>>A question about the recent decision to split the MSRP >>>>>>protocol into a >>>>>>relay-less document and a document that details the use of relays. >>>>>> >>>>>>I would like to understand if the idea is to document the >>>>>>BIND primitive >>>>>>in the relay-less document or in the relayful document. >>>>>> >>>>>>Some folks may argue that the BIND primitive is only used >>>> >>>>in the case >>>> >>>> >>>>>>there are relays in the path, and as such, it should be >>>> >>>>documented in >>>> >>>> >>>>>>the relays document. However, in doing so, we may risk that >>>>>>end points >>>>>>will not implement the BIND primitive ever, and therefore will not >>>>>>support the operation through relays. >>>>>> >>>>>>I am in favour of documenting the BIND primitive in the core MSRP >>>>>>document, in spite that the relay operation will be >>>> >>>>described in the >>>> >>>> >>>>>>relays document. >>>>>> >>>>>>Is this something that the working group is thinking? >>>>>> >>>>>>/Miguel >>>>>>-- >>>>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>>>> Jorvas, Finland >>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>> >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>> >>> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> >>_______________________________________________________________________ > > _ > >>This email has been scanned for all viruses by the MessageLabs Email >>Security System. For more information on a proactive email security >>service working around the clock, around the globe, visit >>http://www.messagelabs.com >>_______________________________________________________________________ > > _ > > ________________________________________________________________________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ________________________________________________________________________ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 09:12:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18126; Tue, 25 Nov 2003 09:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdw8-0005Vm-00; Tue, 25 Nov 2003 09:13:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdw8-0005Vj-00; Tue, 25 Nov 2003 09:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdw5-0002Ps-9X; Tue, 25 Nov 2003 09:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdvS-0002NZ-18 for simple@optimus.ietf.org; Tue, 25 Nov 2003 09:12:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18090 for ; Tue, 25 Nov 2003 09:12:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdvO-0005V8-00 for simple@ietf.org; Tue, 25 Nov 2003 09:12:18 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AOdvN-0005UY-00 for simple@ietf.org; Tue, 25 Nov 2003 09:12:18 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAPEBhE20457 for ; Tue, 25 Nov 2003 08:11:44 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XLN28>; Tue, 25 Nov 2003 14:11:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF29@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Adam Roach , Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:11:41 -0000 Two further comments: 1) At the San Francisco meeting between 3GPP and IETF, back in January, we had a long discussion of what IETF meant by SHOULD, and the view from at least some of the area directors was that effectively they expected to see the SHOULD implemented, and I believe Jonathan put forward the view that allowable reasons for not implementing the SHOULD are best reflected in the specification as further text. Should we therefore add this to bugs list for something that requires additional text in RFC 3265? 2) You mention that this was really intended at INVITE requests. The text as written also applies to REFER dialogs. With respect to SUBSCRIBE dialogs, is not useful to indicate in a SUBSCRIBE response to event A that event package B and C are supported? Is it not the case that presence servers supporting the "presence" event, probably (i.e. SHOULD strength) also support the "presence.winfo" event template. Would it be useful to indicate this support, given that the support of one package is only a SHOULD, given the support of the other, or do you have some other way of determining this information? Thus user A subscribing for the presence of user B would get an indication of whether user A could see other users, e.g. user B, watching him. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 24 November 2003 00:05 > To: Adam Roach; Jonathan Rosenberg > Cc: simple@ietf.org > Subject: [Simple] Question on draft-ietf-simple-presence-10 and > Allow-Events > > > RFC 3265 section 3.3.7 indicates: > > Any node implementing one or more event packages SHOULD include an > appropriate "Allow-Events" header indicating all supported > events in > all methods which initiate dialogs and their responses (such as > INVITE) and OPTIONS responses. > > The SUBSCRIBE request to an event package surely falls into > the category of a method initiating a dialog. > > If I look at draft-ietf-simple-presence-10 then I find no > mention of the Allow-Events header, even though examples are > given for the contents of SUBSCRIBE and NOTIFY methods to > subscribe to the presence event package (section 8). > > So should these examples contain an Allow-Events header value > of "presence" or is the acceptance of a subscription to a > package meant to be one of the cases when the SHOULD in RFC > 3265 does not apply. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > 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 exim@www1.ietf.org Tue Nov 25 09:13:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18151 for ; Tue, 25 Nov 2003 09:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdwA-0002Qj-Gv for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 09:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPED6UK009336 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 09:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdwA-0002QV-Ax for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:13:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18126; Tue, 25 Nov 2003 09:12:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdw8-0005Vm-00; Tue, 25 Nov 2003 09:13:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOdw8-0005Vj-00; Tue, 25 Nov 2003 09:13:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdw5-0002Ps-9X; Tue, 25 Nov 2003 09:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOdvS-0002NZ-18 for simple@optimus.ietf.org; Tue, 25 Nov 2003 09:12:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18090 for ; Tue, 25 Nov 2003 09:12:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOdvO-0005V8-00 for simple@ietf.org; Tue, 25 Nov 2003 09:12:18 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AOdvN-0005UY-00 for simple@ietf.org; Tue, 25 Nov 2003 09:12:18 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAPEBhE20457 for ; Tue, 25 Nov 2003 08:11:44 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XLN28>; Tue, 25 Nov 2003 14:11:42 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF29@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Adam Roach , Jonathan Rosenberg Cc: simple@ietf.org Subject: RE: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:11:41 -0000 Two further comments: 1) At the San Francisco meeting between 3GPP and IETF, back in January, we had a long discussion of what IETF meant by SHOULD, and the view from at least some of the area directors was that effectively they expected to see the SHOULD implemented, and I believe Jonathan put forward the view that allowable reasons for not implementing the SHOULD are best reflected in the specification as further text. Should we therefore add this to bugs list for something that requires additional text in RFC 3265? 2) You mention that this was really intended at INVITE requests. The text as written also applies to REFER dialogs. With respect to SUBSCRIBE dialogs, is not useful to indicate in a SUBSCRIBE response to event A that event package B and C are supported? Is it not the case that presence servers supporting the "presence" event, probably (i.e. SHOULD strength) also support the "presence.winfo" event template. Would it be useful to indicate this support, given that the support of one package is only a SHOULD, given the support of the other, or do you have some other way of determining this information? Thus user A subscribing for the presence of user B would get an indication of whether user A could see other users, e.g. user B, watching him. regards Keith > -----Original Message----- > From: Drage, Keith (Keith) [mailto:drage@lucent.com] > Sent: 24 November 2003 00:05 > To: Adam Roach; Jonathan Rosenberg > Cc: simple@ietf.org > Subject: [Simple] Question on draft-ietf-simple-presence-10 and > Allow-Events > > > RFC 3265 section 3.3.7 indicates: > > Any node implementing one or more event packages SHOULD include an > appropriate "Allow-Events" header indicating all supported > events in > all methods which initiate dialogs and their responses (such as > INVITE) and OPTIONS responses. > > The SUBSCRIBE request to an event package surely falls into > the category of a method initiating a dialog. > > If I look at draft-ietf-simple-presence-10 then I find no > mention of the Allow-Events header, even though examples are > given for the contents of SUBSCRIBE and NOTIFY methods to > subscribe to the presence event package (section 8). > > So should these examples contain an Allow-Events header value > of "presence" or is the acceptance of a subscription to a > package meant to be one of the cases when the SHOULD in RFC > 3265 does not apply. > > regards > > Keith > > Keith Drage > Lucent Technologies > drage@lucent.com > tel: +44 1793 776249 > > _______________________________________________ > 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-admin@ietf.org Tue Nov 25 09:57:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19965; Tue, 25 Nov 2003 09:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOedi-0006Eb-00; Tue, 25 Nov 2003 09:58:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOedi-0006EY-00; Tue, 25 Nov 2003 09:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOede-0005mh-E0; Tue, 25 Nov 2003 09:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOedM-0005kp-1Z for simple@optimus.ietf.org; Tue, 25 Nov 2003 09:57:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19937 for ; Tue, 25 Nov 2003 09:57:28 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOedJ-0006E4-00 for simple@ietf.org; Tue, 25 Nov 2003 09:57:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOedI-0006Dx-00 for simple@ietf.org; Tue, 25 Nov 2003 09:57:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPEvd601161 for ; Tue, 25 Nov 2003 16:57:39 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 16:57:38 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 16:57:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzWzvB8koi2stoSYO/2TlfGJa6dwAB/QZA To: , Cc: , , X-OriginalArrivalTime: 25 Nov 2003 14:57:39.0536 (UTC) FILETIME=[78723D00:01C3B364] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 16:57:34 +0200 Content-Transfer-Encoding: quoted-printable Hi all, I had a different interpreation of the relay discussion in Minneapolis. = I think it should be possible to do an MSRP client without = knowledge/support for relays. The support for relays would be an = extension to this base protocol, and would not need to be included in = all implementations. Also I understood that the basic protocol would be = progressed considerably faster than the extension describing relays. > This=20 > hypothetical situation will allow to deploy clients that do=20 > not support=20 > relays, and this is what I am trying to avoid. Actually, this is what I would like to have in my end-to-end IPv6 = network. I think relayless MSP makes perfect sense if you have a = suitable network for it.=20 Otherwise I don't see a reason to separate the relay draft from the base = draft in the first place. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Miguel A. Garcia > Sent: 25 November, 2003 15:50 > To: Chris Boulton > Cc: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; > simple@ietf.org > Subject: Re: [Simple] BIND and relays documentation >=20 >=20 > Chris: >=20 > I don't find a problem with this approach either. I was=20 > afraid that the=20 > MS(R)P client document will go ahead of the relays document. This=20 > hypothetical situation will allow to deploy clients that do=20 > not support=20 > relays, and this is what I am trying to avoid. >=20 > At least, by reading the minutes of the meeting, I got the impression=20 > that the relays document has to solve certain aspects that=20 > may require=20 > some time to think and discuss. That is the reason why I proposed to=20 > have a first document that supports the BIND operation in the client,=20 > but does not specify how the relay-to-relay connection is done. >=20 > /Miguel >=20 >=20 > Chris Boulton wrote: >=20 > > I personally don't see a problem having an MS(R)P client that is not > > 'relay' aware, as long as the two documents are tightly coupled and > > referenced appropriately. As long as implementers know=20 > categorically > > that for their client to work with Relays, they must=20 > implement reference > > x. > >=20 > > Chris. > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>Sent: 25 November 2003 11:46 > >>To: hisham.khartabil@nokia.com > >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org > >>Subject: Re: [Simple] BIND and relays documentation > >> > >>To me the "half" solution is to document the interaction between the > >>endpoint and the relays in a different document. This sounds a lame > >>solution comparable to not supporting proxies in RFC 3261=20 > or RFC 2616. > >> > >>/Miguel > >> > >>hisham.khartabil@nokia.com wrote: > >> > >> > >>>We will support relays for NAT traversal, in a separate=20 > document. But > >> > >>having half the solution documented is a separate I-D is not > >=20 > > appropriate, > >=20 > >>IMO. > >> > >>>/Hisham > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>>>Sent: 25.November.2003 11:43 > >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org > >>>>Subject: Re: [Simple] BIND and relays documentation > >>>> > >>>> > >>>>This proposal is an incomplete specification. Precluding=20 > support for > >>>>proxies and NAT these days seems a bad idea. If you allow=20 > to have a > >>>>collection of endpoints deployed that do not support=20 > relays, we will > >>>>definitely get problems. > >>>> > >>>>/Miguel > >>>> > >>>>hisham.khartabil@nokia.com wrote: > >>>> > >>>> > >>>> > >>>>>Hi Miguel, > >>>>> > >>>>>I don't agree with you. The relay case will be seen as an > >>>> > >>>>extension of MS(R)P and therefore all methods to support > >>>>relays should be defined in that document. > >>>> > >>>> > >>>>>If endpoint implementers want to support relays for NAT > >>>> > >>>>traversal, then they better implement whatever is documented > >>>>in the relay document. > >>>> > >>>> > >>>>>Regards, > >>>>>Hisham > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: simple-admin@ietf.org > >>>> > >>>>[mailto:simple-admin@ietf.org]On Behalf Of > >>>> > >>>> > >>>>>>ext Miguel A. Garcia > >>>>>>Sent: 24.November.2003 20:48 > >>>>>>To: Ben Campbell > >>>>>>Cc: Simple WG > >>>>>>Subject: [Simple] BIND and relays documentation > >>>>>> > >>>>>> > >>>>>>Hi: > >>>>>> > >>>>>>A question about the recent decision to split the MSRP > >>>>>>protocol into a > >>>>>>relay-less document and a document that details the use=20 > of relays. > >>>>>> > >>>>>>I would like to understand if the idea is to document the > >>>>>>BIND primitive > >>>>>>in the relay-less document or in the relayful document. > >>>>>> > >>>>>>Some folks may argue that the BIND primitive is only used > >>>> > >>>>in the case > >>>> > >>>> > >>>>>>there are relays in the path, and as such, it should be > >>>> > >>>>documented in > >>>> > >>>> > >>>>>>the relays document. However, in doing so, we may risk that > >>>>>>end points > >>>>>>will not implement the BIND primitive ever, and=20 > therefore will not > >>>>>>support the operation through relays. > >>>>>> > >>>>>>I am in favour of documenting the BIND primitive in the=20 > core MSRP > >>>>>>document, in spite that the relay operation will be > >>>> > >>>>described in the > >>>> > >>>> > >>>>>>relays document. > >>>>>> > >>>>>>Is this something that the working group is thinking? > >>>>>> > >>>>>>/Miguel > >>>>>>-- > >>>>>>Miguel-Angel Garcia Oy LM Ericsson AB > >>>>>> Jorvas, Finland > >>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >>>>>> > >>>>>> > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Simple mailing list > >>>>>>Simple@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>>> > >>>>-- > >>>>Miguel-Angel Garcia Oy LM Ericsson AB > >>>> Jorvas, Finland > >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >>>> > >>> > >>> > >>-- > >>Miguel-Angel Garcia Oy LM Ericsson AB > >> Jorvas, Finland > >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> > >>____________________________________________________________ > ___________ > >=20 > > _ > >=20 > >>This email has been scanned for all viruses by the MessageLabs Email > >>Security System. For more information on a proactive email security > >>service working around the clock, around the globe, visit > >>http://www.messagelabs.com > >>____________________________________________________________ > ___________ > >=20 > > _ > >=20 > >=20 > ______________________________________________________________ > __________ > > This email has been scanned for all viruses by the MessageLabs Email > > Security System. For more information on a proactive email security > > service working around the clock, around the globe, visit > > http://www.messagelabs.com > >=20 > ______________________________________________________________ > __________ > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=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 exim@www1.ietf.org Tue Nov 25 09:58:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20018 for ; Tue, 25 Nov 2003 09:58:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOedl-0005qM-Bx for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 09:58:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPEw95A022456 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 09:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOedl-0005q7-6i for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 09:58:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19965; Tue, 25 Nov 2003 09:57:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOedi-0006Eb-00; Tue, 25 Nov 2003 09:58:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOedi-0006EY-00; Tue, 25 Nov 2003 09:58:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOede-0005mh-E0; Tue, 25 Nov 2003 09:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOedM-0005kp-1Z for simple@optimus.ietf.org; Tue, 25 Nov 2003 09:57:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19937 for ; Tue, 25 Nov 2003 09:57:28 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOedJ-0006E4-00 for simple@ietf.org; Tue, 25 Nov 2003 09:57:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOedI-0006Dx-00 for simple@ietf.org; Tue, 25 Nov 2003 09:57:40 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPEvd601161 for ; Tue, 25 Nov 2003 16:57:39 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 16:57:38 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 16:57:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzWzvB8koi2stoSYO/2TlfGJa6dwAB/QZA To: , Cc: , , X-OriginalArrivalTime: 25 Nov 2003 14:57:39.0536 (UTC) FILETIME=[78723D00:01C3B364] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 16:57:34 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, I had a different interpreation of the relay discussion in Minneapolis. = I think it should be possible to do an MSRP client without = knowledge/support for relays. The support for relays would be an = extension to this base protocol, and would not need to be included in = all implementations. Also I understood that the basic protocol would be = progressed considerably faster than the extension describing relays. > This=20 > hypothetical situation will allow to deploy clients that do=20 > not support=20 > relays, and this is what I am trying to avoid. Actually, this is what I would like to have in my end-to-end IPv6 = network. I think relayless MSP makes perfect sense if you have a = suitable network for it.=20 Otherwise I don't see a reason to separate the relay draft from the base = draft in the first place. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Miguel A. Garcia > Sent: 25 November, 2003 15:50 > To: Chris Boulton > Cc: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; > simple@ietf.org > Subject: Re: [Simple] BIND and relays documentation >=20 >=20 > Chris: >=20 > I don't find a problem with this approach either. I was=20 > afraid that the=20 > MS(R)P client document will go ahead of the relays document. This=20 > hypothetical situation will allow to deploy clients that do=20 > not support=20 > relays, and this is what I am trying to avoid. >=20 > At least, by reading the minutes of the meeting, I got the impression=20 > that the relays document has to solve certain aspects that=20 > may require=20 > some time to think and discuss. That is the reason why I proposed to=20 > have a first document that supports the BIND operation in the client,=20 > but does not specify how the relay-to-relay connection is done. >=20 > /Miguel >=20 >=20 > Chris Boulton wrote: >=20 > > I personally don't see a problem having an MS(R)P client that is not > > 'relay' aware, as long as the two documents are tightly coupled and > > referenced appropriately. As long as implementers know=20 > categorically > > that for their client to work with Relays, they must=20 > implement reference > > x. > >=20 > > Chris. > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>Sent: 25 November 2003 11:46 > >>To: hisham.khartabil@nokia.com > >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org > >>Subject: Re: [Simple] BIND and relays documentation > >> > >>To me the "half" solution is to document the interaction between the > >>endpoint and the relays in a different document. This sounds a lame > >>solution comparable to not supporting proxies in RFC 3261=20 > or RFC 2616. > >> > >>/Miguel > >> > >>hisham.khartabil@nokia.com wrote: > >> > >> > >>>We will support relays for NAT traversal, in a separate=20 > document. But > >> > >>having half the solution documented is a separate I-D is not > >=20 > > appropriate, > >=20 > >>IMO. > >> > >>>/Hisham > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>>>Sent: 25.November.2003 11:43 > >>>>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org > >>>>Subject: Re: [Simple] BIND and relays documentation > >>>> > >>>> > >>>>This proposal is an incomplete specification. Precluding=20 > support for > >>>>proxies and NAT these days seems a bad idea. If you allow=20 > to have a > >>>>collection of endpoints deployed that do not support=20 > relays, we will > >>>>definitely get problems. > >>>> > >>>>/Miguel > >>>> > >>>>hisham.khartabil@nokia.com wrote: > >>>> > >>>> > >>>> > >>>>>Hi Miguel, > >>>>> > >>>>>I don't agree with you. The relay case will be seen as an > >>>> > >>>>extension of MS(R)P and therefore all methods to support > >>>>relays should be defined in that document. > >>>> > >>>> > >>>>>If endpoint implementers want to support relays for NAT > >>>> > >>>>traversal, then they better implement whatever is documented > >>>>in the relay document. > >>>> > >>>> > >>>>>Regards, > >>>>>Hisham > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>>-----Original Message----- > >>>>>>From: simple-admin@ietf.org > >>>> > >>>>[mailto:simple-admin@ietf.org]On Behalf Of > >>>> > >>>> > >>>>>>ext Miguel A. Garcia > >>>>>>Sent: 24.November.2003 20:48 > >>>>>>To: Ben Campbell > >>>>>>Cc: Simple WG > >>>>>>Subject: [Simple] BIND and relays documentation > >>>>>> > >>>>>> > >>>>>>Hi: > >>>>>> > >>>>>>A question about the recent decision to split the MSRP > >>>>>>protocol into a > >>>>>>relay-less document and a document that details the use=20 > of relays. > >>>>>> > >>>>>>I would like to understand if the idea is to document the > >>>>>>BIND primitive > >>>>>>in the relay-less document or in the relayful document. > >>>>>> > >>>>>>Some folks may argue that the BIND primitive is only used > >>>> > >>>>in the case > >>>> > >>>> > >>>>>>there are relays in the path, and as such, it should be > >>>> > >>>>documented in > >>>> > >>>> > >>>>>>the relays document. However, in doing so, we may risk that > >>>>>>end points > >>>>>>will not implement the BIND primitive ever, and=20 > therefore will not > >>>>>>support the operation through relays. > >>>>>> > >>>>>>I am in favour of documenting the BIND primitive in the=20 > core MSRP > >>>>>>document, in spite that the relay operation will be > >>>> > >>>>described in the > >>>> > >>>> > >>>>>>relays document. > >>>>>> > >>>>>>Is this something that the working group is thinking? > >>>>>> > >>>>>>/Miguel > >>>>>>-- > >>>>>>Miguel-Angel Garcia Oy LM Ericsson AB > >>>>>> Jorvas, Finland > >>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >>>>>> > >>>>>> > >>>>>> > >>>>>>_______________________________________________ > >>>>>>Simple mailing list > >>>>>>Simple@ietf.org > >>>>>>https://www1.ietf.org/mailman/listinfo/simple > >>>>> > >>>>> > >>>>-- > >>>>Miguel-Angel Garcia Oy LM Ericsson AB > >>>> Jorvas, Finland > >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >>>> > >>> > >>> > >>-- > >>Miguel-Angel Garcia Oy LM Ericsson AB > >> Jorvas, Finland > >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> > >>____________________________________________________________ > ___________ > >=20 > > _ > >=20 > >>This email has been scanned for all viruses by the MessageLabs Email > >>Security System. For more information on a proactive email security > >>service working around the clock, around the globe, visit > >>http://www.messagelabs.com > >>____________________________________________________________ > ___________ > >=20 > > _ > >=20 > >=20 > ______________________________________________________________ > __________ > > This email has been scanned for all viruses by the MessageLabs Email > > Security System. For more information on a proactive email security > > service working around the clock, around the globe, visit > > http://www.messagelabs.com > >=20 > ______________________________________________________________ > __________ > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 > --=20 > Miguel-Angel Garcia Oy LM Ericsson AB > Jorvas, Finland > mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >=20 >=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-admin@ietf.org Tue Nov 25 10:10:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21221; Tue, 25 Nov 2003 10:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeqH-0006QT-00; Tue, 25 Nov 2003 10:11:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOeqG-0006QQ-00; Tue, 25 Nov 2003 10:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeqD-00072Q-4v; Tue, 25 Nov 2003 10:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOepo-00071m-T2 for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:10:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21142 for ; Tue, 25 Nov 2003 10:10:21 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOepm-0006Pu-00 for simple@ietf.org; Tue, 25 Nov 2003 10:10:34 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOepl-0006Pn-00 for simple@ietf.org; Tue, 25 Nov 2003 10:10:33 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPFAVA27268 for ; Tue, 25 Nov 2003 17:10:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 17:10:31 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 17:10:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOyyukxz5eLuGsNTS6xgLByoe+KVwAmdbCQ To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 15:10:31.0079 (UTC) FILETIME=[44525B70:01C3B366] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:10:30 +0200 Content-Transfer-Encoding: quoted-printable Hi, My opinion on extensions is exactly similar to Ben's. I believe we need = the exceptions from day one.=20 I agree that in "open" systems where users can quite freely generate new = IDs, blacklists don't work. However, in enterprises or even in many = commercial public SIP networks, users do get authenticated and user = identity allocation is an administrative process subject to = authentication/authorization. In these environments exceptions are = clearly valuable to users, and leaving them out might mean that SIMPLE = is not considered as flexible as other systems implementing this kind of = features. Leaving external references out of the exceptions is fine, although I = would prefer having them with a rule that if the resolution fails for = some reason, the whole level statement is discarded. (Is = there some reason why this proposal would not work?) Markus =20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 24 November, 2003 22:38 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > This issue consumed a lot of discussion during the Minneapolis IETF. > >=20 > > The current xcap-auth specification adds support for=20 > exceptions within=20 > > the applies-to statements. This allows for a way to say=20 > that a statement=20 > > applies to all the users in a domain or list EXCEPT the=20 > listed set of=20 > > users. This is useful for specifying things like "I want to grant=20 > > permission to everyone in dynamicsoft.com except for Bob".=20 > Presumably=20 > > Bob is an annoying guy and I just don't want to grant him=20 > permission. > >=20 > > Now, a few points need to be made clear about the=20 > exceptions processing. > >=20 > > Firstly, having things like this: > >=20 > > > > > > > > sip:joe@example.com > > > > > >=20 > > is completely useless. The reason is that it is really easy=20 > to obtain=20 > > new names from many namespace providers. As a result, you=20 > may thikn you=20 > > are blocking Joe, but he just goes off, gets a new URI from=20 > yahoo, and=20 > > your permission statement is useless. > > Indeed, the entire notion of except clauses is only useful=20 > if you assume=20 > > that there are cases where it is hard to obtain new=20 > identifiers. There=20 > > was some dispute about whether this is a good assumnption=20 > or not. I, and=20 > > some others, do believe that in many enterprises, it is a good=20 > > assumption that obtaining a new enterprise identifier is not easy. >=20 > While agree that outside of walled-gardens your example is not very=20 > useful, I do think this is very useful when your applies-to=20 > is scoped to=20 > a domain. >=20 > This is not limited to enterprise deployments. It may be true=20 > that some=20 > providers give away identities for free, it is not the case=20 > that _all_=20 > providers do this. In fact, I think the whole argument that you don't=20 > need exceptions becauses identities are free is bogus. >=20 > >=20 > > A second point on exceptions. If an exception represents a=20 > list, and you=20 > > can't dereference that list, then you have to drop the=20 > entire permission=20 > > statement. This is to ensure privacy-safety, so that=20 > information is not=20 > > leaked under any failure condition. > >=20 > > Finally, it needs to be clarified that exceptions still result in=20 > > additive permissions. So, for example, if I have two=20 > staements like this: > >=20 > > > > example.com > > > > sip:sally@example.com > > > > > >=20 > > > >=20 > > and > >=20 > > > > example.com > > > > sip:bob@example.com > > > > > >=20 > > > >=20 > >=20 > >=20 > > That if EITHER Sally or Bob subscribes, they will be=20 > granted permission=20 > > to subscribe. Thats because, if Bob subscribes, the first policy=20 > > statement applies to him, resulting in his subscription=20 > being accepted.=20 > > If Sally subscribes, the second applies to her, and her=20 > subscription is=20 > > accepted. > >=20 > > If you try and make except clauses carry across permission=20 > statements,=20 > > you end up in a place where these statements are no longer=20 > additive, and=20 > > you are not privacy safe anymore. > >=20 > > Now, even given these clarifications, the geopriv group is=20 > not planning=20 > > on specifying an except condition at this time. Though they=20 > consider it=20 > > useful, its been ruled out of scope for the initial policy=20 > document.=20 > > Thus, if we wish to align, we would need to also rule it=20 > out of scope in=20 > > the initial version of the specification. > >=20 > > That does not mean it could never be done; indeed, it would be my=20 > > proposal to more or less immediately have a draft defining it, and=20 > > progress this just behind the main specs. > >=20 > > IMHO, it is worth getting alignment to let this feature=20 > move forward in=20 > > a separate specification, behind the main one. > >=20 > > Comments and thoughts? >=20 > I personally do not think we can live without exceptions, even for a=20 > little while. Since the additive approach does not allow me to=20 > explicitly black-list someone and have that override any other=20 > permissions, then the only way I could create a rule that allowed=20 > everyone from example.com except alice would be to list every single=20 > member of example.com explicitly. This is bad enough from a=20 > convenience=20 > perspective--but in reality it is very unlikely example.com=20 > will share=20 > its membership roster with me, so I could not do this even if=20 > I wanted to. >=20 > I am willing to live with limiting exceptions expressions to=20 > things that=20 > never require external resolution. >=20 > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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 exim@www1.ietf.org Tue Nov 25 10:11:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21305 for ; Tue, 25 Nov 2003 10:11:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeqK-00074j-5C for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:11:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFB8DN027191 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeqK-00074U-1d for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:11:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21221; Tue, 25 Nov 2003 10:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOeqH-0006QT-00; Tue, 25 Nov 2003 10:11:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOeqG-0006QQ-00; Tue, 25 Nov 2003 10:11:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOeqD-00072Q-4v; Tue, 25 Nov 2003 10:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOepo-00071m-T2 for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:10:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21142 for ; Tue, 25 Nov 2003 10:10:21 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOepm-0006Pu-00 for simple@ietf.org; Tue, 25 Nov 2003 10:10:34 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOepl-0006Pn-00 for simple@ietf.org; Tue, 25 Nov 2003 10:10:33 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPFAVA27268 for ; Tue, 25 Nov 2003 17:10:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 17:10:31 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 17:10:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOyyukxz5eLuGsNTS6xgLByoe+KVwAmdbCQ To: , Cc: X-OriginalArrivalTime: 25 Nov 2003 15:10:31.0079 (UTC) FILETIME=[44525B70:01C3B366] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:10:30 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, My opinion on extensions is exactly similar to Ben's. I believe we need = the exceptions from day one.=20 I agree that in "open" systems where users can quite freely generate new = IDs, blacklists don't work. However, in enterprises or even in many = commercial public SIP networks, users do get authenticated and user = identity allocation is an administrative process subject to = authentication/authorization. In these environments exceptions are = clearly valuable to users, and leaving them out might mean that SIMPLE = is not considered as flexible as other systems implementing this kind of = features. Leaving external references out of the exceptions is fine, although I = would prefer having them with a rule that if the resolution fails for = some reason, the whole level statement is discarded. (Is = there some reason why this proposal would not work?) Markus =20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 24 November, 2003 22:38 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > This issue consumed a lot of discussion during the Minneapolis IETF. > >=20 > > The current xcap-auth specification adds support for=20 > exceptions within=20 > > the applies-to statements. This allows for a way to say=20 > that a statement=20 > > applies to all the users in a domain or list EXCEPT the=20 > listed set of=20 > > users. This is useful for specifying things like "I want to grant=20 > > permission to everyone in dynamicsoft.com except for Bob".=20 > Presumably=20 > > Bob is an annoying guy and I just don't want to grant him=20 > permission. > >=20 > > Now, a few points need to be made clear about the=20 > exceptions processing. > >=20 > > Firstly, having things like this: > >=20 > > > > > > > > sip:joe@example.com > > > > > >=20 > > is completely useless. The reason is that it is really easy=20 > to obtain=20 > > new names from many namespace providers. As a result, you=20 > may thikn you=20 > > are blocking Joe, but he just goes off, gets a new URI from=20 > yahoo, and=20 > > your permission statement is useless. > > Indeed, the entire notion of except clauses is only useful=20 > if you assume=20 > > that there are cases where it is hard to obtain new=20 > identifiers. There=20 > > was some dispute about whether this is a good assumnption=20 > or not. I, and=20 > > some others, do believe that in many enterprises, it is a good=20 > > assumption that obtaining a new enterprise identifier is not easy. >=20 > While agree that outside of walled-gardens your example is not very=20 > useful, I do think this is very useful when your applies-to=20 > is scoped to=20 > a domain. >=20 > This is not limited to enterprise deployments. It may be true=20 > that some=20 > providers give away identities for free, it is not the case=20 > that _all_=20 > providers do this. In fact, I think the whole argument that you don't=20 > need exceptions becauses identities are free is bogus. >=20 > >=20 > > A second point on exceptions. If an exception represents a=20 > list, and you=20 > > can't dereference that list, then you have to drop the=20 > entire permission=20 > > statement. This is to ensure privacy-safety, so that=20 > information is not=20 > > leaked under any failure condition. > >=20 > > Finally, it needs to be clarified that exceptions still result in=20 > > additive permissions. So, for example, if I have two=20 > staements like this: > >=20 > > > > example.com > > > > sip:sally@example.com > > > > > >=20 > > > >=20 > > and > >=20 > > > > example.com > > > > sip:bob@example.com > > > > > >=20 > > > >=20 > >=20 > >=20 > > That if EITHER Sally or Bob subscribes, they will be=20 > granted permission=20 > > to subscribe. Thats because, if Bob subscribes, the first policy=20 > > statement applies to him, resulting in his subscription=20 > being accepted.=20 > > If Sally subscribes, the second applies to her, and her=20 > subscription is=20 > > accepted. > >=20 > > If you try and make except clauses carry across permission=20 > statements,=20 > > you end up in a place where these statements are no longer=20 > additive, and=20 > > you are not privacy safe anymore. > >=20 > > Now, even given these clarifications, the geopriv group is=20 > not planning=20 > > on specifying an except condition at this time. Though they=20 > consider it=20 > > useful, its been ruled out of scope for the initial policy=20 > document.=20 > > Thus, if we wish to align, we would need to also rule it=20 > out of scope in=20 > > the initial version of the specification. > >=20 > > That does not mean it could never be done; indeed, it would be my=20 > > proposal to more or less immediately have a draft defining it, and=20 > > progress this just behind the main specs. > >=20 > > IMHO, it is worth getting alignment to let this feature=20 > move forward in=20 > > a separate specification, behind the main one. > >=20 > > Comments and thoughts? >=20 > I personally do not think we can live without exceptions, even for a=20 > little while. Since the additive approach does not allow me to=20 > explicitly black-list someone and have that override any other=20 > permissions, then the only way I could create a rule that allowed=20 > everyone from example.com except alice would be to list every single=20 > member of example.com explicitly. This is bad enough from a=20 > convenience=20 > perspective--but in reality it is very unlikely example.com=20 > will share=20 > its membership roster with me, so I could not do this even if=20 > I wanted to. >=20 > I am willing to live with limiting exceptions expressions to=20 > things that=20 > never require external resolution. >=20 > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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-admin@ietf.org Tue Nov 25 10:21:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22225; Tue, 25 Nov 2003 10:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf0x-0006iI-00; Tue, 25 Nov 2003 10:22:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf0x-0006iF-00; Tue, 25 Nov 2003 10:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf0s-0007za-S9; Tue, 25 Nov 2003 10:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf0l-0007zB-Sy for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:21:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22215 for ; Tue, 25 Nov 2003 10:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf0j-0006hk-00 for simple@ietf.org; Tue, 25 Nov 2003 10:21:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOf0i-0006hF-00 for simple@ietf.org; Tue, 25 Nov 2003 10:21:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFLUnG018119; Tue, 25 Nov 2003 09:21:41 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3736C.6030308@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B109@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B109@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:21:16 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 24.November.2003 22:38 >>To: Jonathan Rosenberg >>Cc: Simple WG >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >> >> >>Jonathan Rosenberg wrote: >> >> >>>This issue consumed a lot of discussion during the Minneapolis IETF. >>> >>>The current xcap-auth specification adds support for >> >>exceptions within >> >>>the applies-to statements. This allows for a way to say >> >>that a statement >> >>>applies to all the users in a domain or list EXCEPT the >> >>listed set of >> >>>users. This is useful for specifying things like "I want to grant >>>permission to everyone in dynamicsoft.com except for Bob". >> >>Presumably >> >>>Bob is an annoying guy and I just don't want to grant him >> >>permission. >> >>>Now, a few points need to be made clear about the >> >>exceptions processing. >> >>>Firstly, having things like this: >>> >>> >>> >>> >>> sip:joe@example.com >>> >>> >>> >>>is completely useless. The reason is that it is really easy >> >>to obtain >> >>>new names from many namespace providers. As a result, you >> >>may thikn you >> >>>are blocking Joe, but he just goes off, gets a new URI from >> >>yahoo, and >> >>>your permission statement is useless. >>>Indeed, the entire notion of except clauses is only useful >> >>if you assume >> >>>that there are cases where it is hard to obtain new >> >>identifiers. There >> >>>was some dispute about whether this is a good assumnption >> >>or not. I, and >> >>>some others, do believe that in many enterprises, it is a good >>>assumption that obtaining a new enterprise identifier is not easy. >> >>While agree that outside of walled-gardens your example is not very >>useful, I do think this is very useful when your applies-to >>is scoped to >>a domain. >> >>This is not limited to enterprise deployments. It may be true >>that some >>providers give away identities for free, it is not the case >>that _all_ >>providers do this. In fact, I think the whole argument that you don't >>need exceptions becauses identities are free is bogus. >> >> >>>A second point on exceptions. If an exception represents a >> >>list, and you >> >>>can't dereference that list, then you have to drop the >> >>entire permission >> >>>statement. This is to ensure privacy-safety, so that >> >>information is not >> >>>leaked under any failure condition. >>> >>>Finally, it needs to be clarified that exceptions still result in >>>additive permissions. So, for example, if I have two >> >>staements like this: >> >>> >>> example.com >>> >>> sip:sally@example.com >>> >>> >>> >>> >>> >>>and >>> >>> >>> example.com >>> >>> sip:bob@example.com >>> >>> >>> >>> >>> >>> >>> >>>That if EITHER Sally or Bob subscribes, they will be >> >>granted permission >> >>>to subscribe. Thats because, if Bob subscribes, the first policy >>>statement applies to him, resulting in his subscription >> >>being accepted. >> >>>If Sally subscribes, the second applies to her, and her >> >>subscription is >> >>>accepted. >>> >>>If you try and make except clauses carry across permission >> >>statements, >> >>>you end up in a place where these statements are no longer >> >>additive, and >> >>>you are not privacy safe anymore. >>> >>>Now, even given these clarifications, the geopriv group is >> >>not planning >> >>>on specifying an except condition at this time. Though they >> >>consider it >> >>>useful, its been ruled out of scope for the initial policy >> >>document. >> >>>Thus, if we wish to align, we would need to also rule it >> >>out of scope in >> >>>the initial version of the specification. >>> >>>That does not mean it could never be done; indeed, it would be my >>>proposal to more or less immediately have a draft defining it, and >>>progress this just behind the main specs. >>> >>>IMHO, it is worth getting alignment to let this feature >> >>move forward in >> >>>a separate specification, behind the main one. >>> >>>Comments and thoughts? >> >>I personally do not think we can live without exceptions, even for a >>little while. Since the additive approach does not allow me to >>explicitly black-list someone and have that override any other >>permissions, then the only way I could create a rule that allowed >>everyone from example.com except alice would be to list every single >>member of example.com explicitly. This is bad enough from a >>convenience >>perspective--but in reality it is very unlikely example.com >>will share >>its membership roster with me, so I could not do this even if >>I wanted to. > > > The way it works today is that you have a list of presentities and a list of watchers. The list of watchers is what the issues are about. In most systems today, the list of watchers is a mirror to the list of presentities, and therefore does not include everyone is a domain. > > I think it is ok for now to give permissions to individual watchers as selected by the presentity. We are not at a stage in presence systems where we want to allow everyone at a domain to view someone's presence excepting individual x and y. But more like 15 to 20 individuals that the presentity mostly interacts with in that domain. > > So, instead of allowing, for example, everyone at example.com except for Bob. I can pick john, alice, ben and adam from example.com that I interact with and want to allow to be my watchers, and create permissions for them. This leaves out bob along with everyone else at example.com. I think this is good enough. So you have allowed John, Alice, Ben and Adam. That is _not_ the same as "Everyone but Bob". For example, what if Carol joins example.com tomorrow. The "Allow John, Alice, Ben, and Adam" rule will not include her, but the "Everyone but Bob rule" would. Most of the existing systems that mirror the watcher and presentity lists are single-domain systems. In an interoperable, multidomain system, I think that policy needs will quickly outstrip the expressivity of the rule language if you don't have exceptions. > > Regards, > Hisham > > >>I am willing to live with limiting exceptions expressions to >>things that >>never require external resolution. >> >> >>>Thanks, >>>Jonathan R. >> >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Tue Nov 25 10:22:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22292 for ; Tue, 25 Nov 2003 10:22:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf11-000859-2j for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:22:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFMBj3031066 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:22:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf10-00084z-Va for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:22:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22225; Tue, 25 Nov 2003 10:21:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf0x-0006iI-00; Tue, 25 Nov 2003 10:22:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf0x-0006iF-00; Tue, 25 Nov 2003 10:22:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf0s-0007za-S9; Tue, 25 Nov 2003 10:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf0l-0007zB-Sy for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:21:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22215 for ; Tue, 25 Nov 2003 10:21:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf0j-0006hk-00 for simple@ietf.org; Tue, 25 Nov 2003 10:21:53 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOf0i-0006hF-00 for simple@ietf.org; Tue, 25 Nov 2003 10:21:52 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFLUnG018119; Tue, 25 Nov 2003 09:21:41 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3736C.6030308@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B109@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B109@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:21:16 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 24.November.2003 22:38 >>To: Jonathan Rosenberg >>Cc: Simple WG >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >> >> >>Jonathan Rosenberg wrote: >> >> >>>This issue consumed a lot of discussion during the Minneapolis IETF. >>> >>>The current xcap-auth specification adds support for >> >>exceptions within >> >>>the applies-to statements. This allows for a way to say >> >>that a statement >> >>>applies to all the users in a domain or list EXCEPT the >> >>listed set of >> >>>users. This is useful for specifying things like "I want to grant >>>permission to everyone in dynamicsoft.com except for Bob". >> >>Presumably >> >>>Bob is an annoying guy and I just don't want to grant him >> >>permission. >> >>>Now, a few points need to be made clear about the >> >>exceptions processing. >> >>>Firstly, having things like this: >>> >>> >>> >>> >>> sip:joe@example.com >>> >>> >>> >>>is completely useless. The reason is that it is really easy >> >>to obtain >> >>>new names from many namespace providers. As a result, you >> >>may thikn you >> >>>are blocking Joe, but he just goes off, gets a new URI from >> >>yahoo, and >> >>>your permission statement is useless. >>>Indeed, the entire notion of except clauses is only useful >> >>if you assume >> >>>that there are cases where it is hard to obtain new >> >>identifiers. There >> >>>was some dispute about whether this is a good assumnption >> >>or not. I, and >> >>>some others, do believe that in many enterprises, it is a good >>>assumption that obtaining a new enterprise identifier is not easy. >> >>While agree that outside of walled-gardens your example is not very >>useful, I do think this is very useful when your applies-to >>is scoped to >>a domain. >> >>This is not limited to enterprise deployments. It may be true >>that some >>providers give away identities for free, it is not the case >>that _all_ >>providers do this. In fact, I think the whole argument that you don't >>need exceptions becauses identities are free is bogus. >> >> >>>A second point on exceptions. If an exception represents a >> >>list, and you >> >>>can't dereference that list, then you have to drop the >> >>entire permission >> >>>statement. This is to ensure privacy-safety, so that >> >>information is not >> >>>leaked under any failure condition. >>> >>>Finally, it needs to be clarified that exceptions still result in >>>additive permissions. So, for example, if I have two >> >>staements like this: >> >>> >>> example.com >>> >>> sip:sally@example.com >>> >>> >>> >>> >>> >>>and >>> >>> >>> example.com >>> >>> sip:bob@example.com >>> >>> >>> >>> >>> >>> >>> >>>That if EITHER Sally or Bob subscribes, they will be >> >>granted permission >> >>>to subscribe. Thats because, if Bob subscribes, the first policy >>>statement applies to him, resulting in his subscription >> >>being accepted. >> >>>If Sally subscribes, the second applies to her, and her >> >>subscription is >> >>>accepted. >>> >>>If you try and make except clauses carry across permission >> >>statements, >> >>>you end up in a place where these statements are no longer >> >>additive, and >> >>>you are not privacy safe anymore. >>> >>>Now, even given these clarifications, the geopriv group is >> >>not planning >> >>>on specifying an except condition at this time. Though they >> >>consider it >> >>>useful, its been ruled out of scope for the initial policy >> >>document. >> >>>Thus, if we wish to align, we would need to also rule it >> >>out of scope in >> >>>the initial version of the specification. >>> >>>That does not mean it could never be done; indeed, it would be my >>>proposal to more or less immediately have a draft defining it, and >>>progress this just behind the main specs. >>> >>>IMHO, it is worth getting alignment to let this feature >> >>move forward in >> >>>a separate specification, behind the main one. >>> >>>Comments and thoughts? >> >>I personally do not think we can live without exceptions, even for a >>little while. Since the additive approach does not allow me to >>explicitly black-list someone and have that override any other >>permissions, then the only way I could create a rule that allowed >>everyone from example.com except alice would be to list every single >>member of example.com explicitly. This is bad enough from a >>convenience >>perspective--but in reality it is very unlikely example.com >>will share >>its membership roster with me, so I could not do this even if >>I wanted to. > > > The way it works today is that you have a list of presentities and a list of watchers. The list of watchers is what the issues are about. In most systems today, the list of watchers is a mirror to the list of presentities, and therefore does not include everyone is a domain. > > I think it is ok for now to give permissions to individual watchers as selected by the presentity. We are not at a stage in presence systems where we want to allow everyone at a domain to view someone's presence excepting individual x and y. But more like 15 to 20 individuals that the presentity mostly interacts with in that domain. > > So, instead of allowing, for example, everyone at example.com except for Bob. I can pick john, alice, ben and adam from example.com that I interact with and want to allow to be my watchers, and create permissions for them. This leaves out bob along with everyone else at example.com. I think this is good enough. So you have allowed John, Alice, Ben and Adam. That is _not_ the same as "Everyone but Bob". For example, what if Carol joins example.com tomorrow. The "Allow John, Alice, Ben, and Adam" rule will not include her, but the "Everyone but Bob rule" would. Most of the existing systems that mirror the watcher and presentity lists are single-domain systems. In an interoperable, multidomain system, I think that policy needs will quickly outstrip the expressivity of the rule language if you don't have exceptions. > > Regards, > Hisham > > >>I am willing to live with limiting exceptions expressions to >>things that >>never require external resolution. >> >> >>>Thanks, >>>Jonathan R. >> >> >> >>_______________________________________________ >>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-admin@ietf.org Tue Nov 25 10:23:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22361; Tue, 25 Nov 2003 10:23:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf2w-0006lr-00; Tue, 25 Nov 2003 10:24:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf2v-0006lo-00; Tue, 25 Nov 2003 10:24:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2s-0008Ic-EX; Tue, 25 Nov 2003 10:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf2R-0008FO-60 for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:23:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22331 for ; Tue, 25 Nov 2003 10:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf2O-0006kc-00 for simple@ietf.org; Tue, 25 Nov 2003 10:23:37 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOf2O-0006kY-00 for simple@ietf.org; Tue, 25 Nov 2003 10:23:36 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFNYnG018332; Tue, 25 Nov 2003 09:23:34 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC373EF.1010404@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <2038BCC78B1AD641891A0D1AE133DBB701797432@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797432@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:23:27 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 24.November.2003 23:00 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: jdrosen@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>Can the user at least have a say in accepting or rejecting >> >>the subscription based on the availability of any >>authentication type. Eg: A user can reject subscriptions that >>are not authenticated in any way and accept subscriptions >>that are authenticated, regardless of authentication type. >> >>In the absence of _some_ authentication, what is the value of having >>authorization policies in the first place? They have no >>meaning if you >>cannot put some degree of trust in the requestor identity. >> >>I think the email world has proven to us how useful it is to >>authorize >>on un-authenticated headers. How useful is a spam filter that >>relies on >>the From header? > > > Either I'm missing your point, or you missed mine. All I said was that the user should be able to reject subscriptions if they are not authenticated (authentication method is irrelevant). > Ah, well, I can't disagree with that :-) Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 10:29:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22758; Tue, 25 Nov 2003 10:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8i-0006vf-00; Tue, 25 Nov 2003 10:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf8i-0006vc-00; Tue, 25 Nov 2003 10:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8e-0000lm-IR; Tue, 25 Nov 2003 10:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8W-0000l2-Jr for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22752 for ; Tue, 25 Nov 2003 10:29:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8U-0006vT-00 for simple@ietf.org; Tue, 25 Nov 2003 10:29:54 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOf8T-0006vQ-00 for simple@ietf.org; Tue, 25 Nov 2003 10:29:53 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFTinG018867; Tue, 25 Nov 2003 09:29:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC37561.6020209@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> <3FC262B4.5040802@ericsson.com> <3FC26428.8040702@dynamicsoft.com> <3FC323B1.9050709@ericsson.com> In-Reply-To: <3FC323B1.9050709@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:29:37 -0600 Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Inline. > > > Ben Campbell wrote: > >> Miguel A. Garcia wrote: >> >>> I don't think I really agree. An endpoint that is configured to use >>> a relay needs to know that it has to start the session by getting the >>> MSRP URI from the relay itself, with a BIND primitive. Then it needs >>> to know that the URI it got is the one he populates in the SDP. >> >> >> >> That is exactly the knowledge I was talking about. Additionally, it >> has to know that relays are even possible to start out with, which >> implies knowledge of the relay specification. > > > The relays that are possible are not dependent on the use of BIND. It is > just a matter of configuration, it does not affect the procedures. The > UE will send a BIND in the same manner to the relay, providing that it > knows (configured with) the relay address. > >> >> My understanding of the mandate to remove relays from the base spec is >> that an endpoint that implements the base spec, and not the relay >> extension, does not know that relays even exist. Furthermore, until we >> complete the relay specification, we cannot know exactly how BIND >> should work. I don't think we can put a constraint on the relay >> specification that prevents it from changing the way you request a relay. > > > Maybe I have a missunderstanding here, but as far as I understand from > the SIMPLE minutes, the problem with relays lies in the relay-to-relay > communication, because if the issues already discussed in the list with > multiplexing and head of line blocking. As far as I understand, the > problem does not affect the endpoint-to-relay session (does it?). That is the most significant thing slowing down the specification of relays. But the hum was about removing relays from the base spec entirely. > > What I am trying to avoid is that there are implementations of MSRP that > will not support relays. It would be similar to not describing proxies > in RFC 2616, and therefore, having web browsers that do not support > proxies. I agree that would be nice, but as a practical matter, we don't want to make the base spec wait on getting all relay issues ironed out. It is not at all unlikely that changes to our previous thinking about how relays would work will change the way that an endpoint interacts with a relay. For example, changes in the inter-relay protocol may change what information has to be advertised in SDP and included in BIND or its equivilent. I really do not see how we can specify how endpoints use relays when relays have not yet been specified. > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 10:30:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22823 for ; Tue, 25 Nov 2003 10:30:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8l-0000sb-PQ for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFUBMC003375 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8l-0000sM-Fu for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:30:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22758; Tue, 25 Nov 2003 10:29:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8i-0006vf-00; Tue, 25 Nov 2003 10:30:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf8i-0006vc-00; Tue, 25 Nov 2003 10:30:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8e-0000lm-IR; Tue, 25 Nov 2003 10:30:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8W-0000l2-Jr for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:29:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22752 for ; Tue, 25 Nov 2003 10:29:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8U-0006vT-00 for simple@ietf.org; Tue, 25 Nov 2003 10:29:54 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOf8T-0006vQ-00 for simple@ietf.org; Tue, 25 Nov 2003 10:29:53 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFTinG018867; Tue, 25 Nov 2003 09:29:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC37561.6020209@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: Simple WG References: <3FC25259.1060804@ericsson.com> <3FC253F0.6090905@dynamicsoft.com> <3FC262B4.5040802@ericsson.com> <3FC26428.8040702@dynamicsoft.com> <3FC323B1.9050709@ericsson.com> In-Reply-To: <3FC323B1.9050709@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: BIND and relays documentation Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:29:37 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > Inline. > > > Ben Campbell wrote: > >> Miguel A. Garcia wrote: >> >>> I don't think I really agree. An endpoint that is configured to use >>> a relay needs to know that it has to start the session by getting the >>> MSRP URI from the relay itself, with a BIND primitive. Then it needs >>> to know that the URI it got is the one he populates in the SDP. >> >> >> >> That is exactly the knowledge I was talking about. Additionally, it >> has to know that relays are even possible to start out with, which >> implies knowledge of the relay specification. > > > The relays that are possible are not dependent on the use of BIND. It is > just a matter of configuration, it does not affect the procedures. The > UE will send a BIND in the same manner to the relay, providing that it > knows (configured with) the relay address. > >> >> My understanding of the mandate to remove relays from the base spec is >> that an endpoint that implements the base spec, and not the relay >> extension, does not know that relays even exist. Furthermore, until we >> complete the relay specification, we cannot know exactly how BIND >> should work. I don't think we can put a constraint on the relay >> specification that prevents it from changing the way you request a relay. > > > Maybe I have a missunderstanding here, but as far as I understand from > the SIMPLE minutes, the problem with relays lies in the relay-to-relay > communication, because if the issues already discussed in the list with > multiplexing and head of line blocking. As far as I understand, the > problem does not affect the endpoint-to-relay session (does it?). That is the most significant thing slowing down the specification of relays. But the hum was about removing relays from the base spec entirely. > > What I am trying to avoid is that there are implementations of MSRP that > will not support relays. It would be similar to not describing proxies > in RFC 2616, and therefore, having web browsers that do not support > proxies. I agree that would be nice, but as a practical matter, we don't want to make the base spec wait on getting all relay issues ironed out. It is not at all unlikely that changes to our previous thinking about how relays would work will change the way that an endpoint interacts with a relay. For example, changes in the inter-relay protocol may change what information has to be advertised in SDP and included in BIND or its equivilent. I really do not see how we can specify how endpoints use relays when relays have not yet been specified. > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 10:30:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22873; Tue, 25 Nov 2003 10:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf9Y-0006wo-00; Tue, 25 Nov 2003 10:31:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf9Y-0006wl-00; Tue, 25 Nov 2003 10:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf9Z-00010e-GP; Tue, 25 Nov 2003 10:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8t-0000vd-CU for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:30:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22786 for ; Tue, 25 Nov 2003 10:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8q-0006vt-00 for simple@ietf.org; Tue, 25 Nov 2003 10:30:16 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8q-0006vp-00 for simple@ietf.org; Tue, 25 Nov 2003 10:30:16 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPFU7Ss023168; Tue, 25 Nov 2003 16:30:08 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XTFSLQAL; Tue, 25 Nov 2003 16:30:12 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CEEA18A82; Tue, 25 Nov 2003 17:30:06 +0200 (EET) Message-ID: <3FC3757D.7040400@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Cc: cboulton@ubiquity.net, hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:30:05 +0200 Content-Transfer-Encoding: 7bit Markus: You just showed an example where you don't need relays (IPv6 network, no policy, etc). I am fine with the example. Unfortunately the market seems to be thinking of IPv4, NATs, and policies that requires to visit a relay. In that situation the endpoint will not be able to send MSRP traffic to the peer endpoint. It sounds a bit strange that we are heading to a situation where people are trying to preclude support for relays just because they are not needed in your particular application. Again, think of the HTTP or SIP situation, and think if it makes sense to deploy clients that do not support HTTP and SIP. /Miguel Markus.Isomaki@nokia.com wrote: > Hi all, > > I had a different interpreation of the relay discussion in Minneapolis. I think it should be possible to do an MSRP client without knowledge/support for relays. The support for relays would be an extension to this base protocol, and would not need to be included in all implementations. Also I understood that the basic protocol would be progressed considerably faster than the extension describing relays. > > >>This >>hypothetical situation will allow to deploy clients that do >>not support >>relays, and this is what I am trying to avoid. > > > Actually, this is what I would like to have in my end-to-end IPv6 network. I think relayless MSP makes perfect sense if you have a suitable network for it. > > Otherwise I don't see a reason to separate the relay draft from the base draft in the first place. > > Markus > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Miguel A. Garcia >>Sent: 25 November, 2003 15:50 >>To: Chris Boulton >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >> >>Chris: >> >>I don't find a problem with this approach either. I was >>afraid that the >>MS(R)P client document will go ahead of the relays document. This >>hypothetical situation will allow to deploy clients that do >>not support >>relays, and this is what I am trying to avoid. >> >>At least, by reading the minutes of the meeting, I got the impression >>that the relays document has to solve certain aspects that >>may require >>some time to think and discuss. That is the reason why I proposed to >>have a first document that supports the BIND operation in the client, >>but does not specify how the relay-to-relay connection is done. >> >>/Miguel >> >> >>Chris Boulton wrote: >> >> >>>I personally don't see a problem having an MS(R)P client that is not >>>'relay' aware, as long as the two documents are tightly coupled and >>>referenced appropriately. As long as implementers know >> >>categorically >> >>>that for their client to work with Relays, they must >> >>implement reference >> >>>x. >>> >>>Chris. >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>Sent: 25 November 2003 11:46 >>>>To: hisham.khartabil@nokia.com >>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>>>Subject: Re: [Simple] BIND and relays documentation >>>> >>>>To me the "half" solution is to document the interaction between the >>>>endpoint and the relays in a different document. This sounds a lame >>>>solution comparable to not supporting proxies in RFC 3261 >> >>or RFC 2616. >> >>>>/Miguel >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>> >>>> >>>>>We will support relays for NAT traversal, in a separate >> >>document. But >> >>>>having half the solution documented is a separate I-D is not >>> >>>appropriate, >>> >>> >>>>IMO. >>>> >>>> >>>>>/Hisham >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>>>Sent: 25.November.2003 11:43 >>>>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>>Subject: Re: [Simple] BIND and relays documentation >>>>>> >>>>>> >>>>>>This proposal is an incomplete specification. Precluding >> >>support for >> >>>>>>proxies and NAT these days seems a bad idea. If you allow >> >>to have a >> >>>>>>collection of endpoints deployed that do not support >> >>relays, we will >> >>>>>>definitely get problems. >>>>>> >>>>>>/Miguel >>>>>> >>>>>>hisham.khartabil@nokia.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Miguel, >>>>>>> >>>>>>>I don't agree with you. The relay case will be seen as an >>>>>> >>>>>>extension of MS(R)P and therefore all methods to support >>>>>>relays should be defined in that document. >>>>>> >>>>>> >>>>>> >>>>>>>If endpoint implementers want to support relays for NAT >>>>>> >>>>>>traversal, then they better implement whatever is documented >>>>>>in the relay document. >>>>>> >>>>>> >>>>>> >>>>>>>Regards, >>>>>>>Hisham >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: simple-admin@ietf.org >>>>>> >>>>>>[mailto:simple-admin@ietf.org]On Behalf Of >>>>>> >>>>>> >>>>>> >>>>>>>>ext Miguel A. Garcia >>>>>>>>Sent: 24.November.2003 20:48 >>>>>>>>To: Ben Campbell >>>>>>>>Cc: Simple WG >>>>>>>>Subject: [Simple] BIND and relays documentation >>>>>>>> >>>>>>>> >>>>>>>>Hi: >>>>>>>> >>>>>>>>A question about the recent decision to split the MSRP >>>>>>>>protocol into a >>>>>>>>relay-less document and a document that details the use >> >>of relays. >> >>>>>>>>I would like to understand if the idea is to document the >>>>>>>>BIND primitive >>>>>>>>in the relay-less document or in the relayful document. >>>>>>>> >>>>>>>>Some folks may argue that the BIND primitive is only used >>>>>> >>>>>>in the case >>>>>> >>>>>> >>>>>> >>>>>>>>there are relays in the path, and as such, it should be >>>>>> >>>>>>documented in >>>>>> >>>>>> >>>>>> >>>>>>>>the relays document. However, in doing so, we may risk that >>>>>>>>end points >>>>>>>>will not implement the BIND primitive ever, and >> >>therefore will not >> >>>>>>>>support the operation through relays. >>>>>>>> >>>>>>>>I am in favour of documenting the BIND primitive in the >> >>core MSRP >> >>>>>>>>document, in spite that the relay operation will be >>>>>> >>>>>>described in the >>>>>> >>>>>> >>>>>> >>>>>>>>relays document. >>>>>>>> >>>>>>>>Is this something that the working group is thinking? >>>>>>>> >>>>>>>>/Miguel >>>>>>>>-- >>>>>>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>>>>>> Jorvas, Finland >>>>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Simple mailing list >>>>>>>>Simple@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>>> >>>>>>-- >>>>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>>>> Jorvas, Finland >>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>>>> >>>>> >>>>> >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>>____________________________________________________________ >> >>___________ >> >>>_ >>> >>> >>>>This email has been scanned for all viruses by the MessageLabs Email >>>>Security System. For more information on a proactive email security >>>>service working around the clock, around the globe, visit >>>>http://www.messagelabs.com >>>>____________________________________________________________ >> >>___________ >> >>>_ >>> >>> >> >>______________________________________________________________ >>__________ >> >>>This email has been scanned for all viruses by the MessageLabs Email >>>Security System. For more information on a proactive email security >>>service working around the clock, around the globe, visit >>>http://www.messagelabs.com >>> >> >>______________________________________________________________ >>__________ >> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >>_______________________________________________ >>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 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 10:31:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22947 for ; Tue, 25 Nov 2003 10:31:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf9c-000134-2P for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:31:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFV3Dl004023 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf9b-00012o-QH for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:31:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22873; Tue, 25 Nov 2003 10:30:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf9Y-0006wo-00; Tue, 25 Nov 2003 10:31:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOf9Y-0006wl-00; Tue, 25 Nov 2003 10:31:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf9Z-00010e-GP; Tue, 25 Nov 2003 10:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOf8t-0000vd-CU for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:30:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22786 for ; Tue, 25 Nov 2003 10:30:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8q-0006vt-00 for simple@ietf.org; Tue, 25 Nov 2003 10:30:16 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AOf8q-0006vp-00 for simple@ietf.org; Tue, 25 Nov 2003 10:30:16 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAPFU7Ss023168; Tue, 25 Nov 2003 16:30:08 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XTFSLQAL; Tue, 25 Nov 2003 16:30:12 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.244]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CEEA18A82; Tue, 25 Nov 2003 17:30:06 +0200 (EET) Message-ID: <3FC3757D.7040400@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Markus.Isomaki@nokia.com Cc: cboulton@ubiquity.net, hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:30:05 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus: You just showed an example where you don't need relays (IPv6 network, no policy, etc). I am fine with the example. Unfortunately the market seems to be thinking of IPv4, NATs, and policies that requires to visit a relay. In that situation the endpoint will not be able to send MSRP traffic to the peer endpoint. It sounds a bit strange that we are heading to a situation where people are trying to preclude support for relays just because they are not needed in your particular application. Again, think of the HTTP or SIP situation, and think if it makes sense to deploy clients that do not support HTTP and SIP. /Miguel Markus.Isomaki@nokia.com wrote: > Hi all, > > I had a different interpreation of the relay discussion in Minneapolis. I think it should be possible to do an MSRP client without knowledge/support for relays. The support for relays would be an extension to this base protocol, and would not need to be included in all implementations. Also I understood that the basic protocol would be progressed considerably faster than the extension describing relays. > > >>This >>hypothetical situation will allow to deploy clients that do >>not support >>relays, and this is what I am trying to avoid. > > > Actually, this is what I would like to have in my end-to-end IPv6 network. I think relayless MSP makes perfect sense if you have a suitable network for it. > > Otherwise I don't see a reason to separate the relay draft from the base draft in the first place. > > Markus > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Miguel A. Garcia >>Sent: 25 November, 2003 15:50 >>To: Chris Boulton >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); bcampbell@dynamicsoft.com; >>simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >> >>Chris: >> >>I don't find a problem with this approach either. I was >>afraid that the >>MS(R)P client document will go ahead of the relays document. This >>hypothetical situation will allow to deploy clients that do >>not support >>relays, and this is what I am trying to avoid. >> >>At least, by reading the minutes of the meeting, I got the impression >>that the relays document has to solve certain aspects that >>may require >>some time to think and discuss. That is the reason why I proposed to >>have a first document that supports the BIND operation in the client, >>but does not specify how the relay-to-relay connection is done. >> >>/Miguel >> >> >>Chris Boulton wrote: >> >> >>>I personally don't see a problem having an MS(R)P client that is not >>>'relay' aware, as long as the two documents are tightly coupled and >>>referenced appropriately. As long as implementers know >> >>categorically >> >>>that for their client to work with Relays, they must >> >>implement reference >> >>>x. >>> >>>Chris. >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>Sent: 25 November 2003 11:46 >>>>To: hisham.khartabil@nokia.com >>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>>>Subject: Re: [Simple] BIND and relays documentation >>>> >>>>To me the "half" solution is to document the interaction between the >>>>endpoint and the relays in a different document. This sounds a lame >>>>solution comparable to not supporting proxies in RFC 3261 >> >>or RFC 2616. >> >>>>/Miguel >>>> >>>>hisham.khartabil@nokia.com wrote: >>>> >>>> >>>> >>>>>We will support relays for NAT traversal, in a separate >> >>document. But >> >>>>having half the solution documented is a separate I-D is not >>> >>>appropriate, >>> >>> >>>>IMO. >>>> >>>> >>>>>/Hisham >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>>>>>Sent: 25.November.2003 11:43 >>>>>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>>>>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>>>>>Subject: Re: [Simple] BIND and relays documentation >>>>>> >>>>>> >>>>>>This proposal is an incomplete specification. Precluding >> >>support for >> >>>>>>proxies and NAT these days seems a bad idea. If you allow >> >>to have a >> >>>>>>collection of endpoints deployed that do not support >> >>relays, we will >> >>>>>>definitely get problems. >>>>>> >>>>>>/Miguel >>>>>> >>>>>>hisham.khartabil@nokia.com wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Hi Miguel, >>>>>>> >>>>>>>I don't agree with you. The relay case will be seen as an >>>>>> >>>>>>extension of MS(R)P and therefore all methods to support >>>>>>relays should be defined in that document. >>>>>> >>>>>> >>>>>> >>>>>>>If endpoint implementers want to support relays for NAT >>>>>> >>>>>>traversal, then they better implement whatever is documented >>>>>>in the relay document. >>>>>> >>>>>> >>>>>> >>>>>>>Regards, >>>>>>>Hisham >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: simple-admin@ietf.org >>>>>> >>>>>>[mailto:simple-admin@ietf.org]On Behalf Of >>>>>> >>>>>> >>>>>> >>>>>>>>ext Miguel A. Garcia >>>>>>>>Sent: 24.November.2003 20:48 >>>>>>>>To: Ben Campbell >>>>>>>>Cc: Simple WG >>>>>>>>Subject: [Simple] BIND and relays documentation >>>>>>>> >>>>>>>> >>>>>>>>Hi: >>>>>>>> >>>>>>>>A question about the recent decision to split the MSRP >>>>>>>>protocol into a >>>>>>>>relay-less document and a document that details the use >> >>of relays. >> >>>>>>>>I would like to understand if the idea is to document the >>>>>>>>BIND primitive >>>>>>>>in the relay-less document or in the relayful document. >>>>>>>> >>>>>>>>Some folks may argue that the BIND primitive is only used >>>>>> >>>>>>in the case >>>>>> >>>>>> >>>>>> >>>>>>>>there are relays in the path, and as such, it should be >>>>>> >>>>>>documented in >>>>>> >>>>>> >>>>>> >>>>>>>>the relays document. However, in doing so, we may risk that >>>>>>>>end points >>>>>>>>will not implement the BIND primitive ever, and >> >>therefore will not >> >>>>>>>>support the operation through relays. >>>>>>>> >>>>>>>>I am in favour of documenting the BIND primitive in the >> >>core MSRP >> >>>>>>>>document, in spite that the relay operation will be >>>>>> >>>>>>described in the >>>>>> >>>>>> >>>>>> >>>>>>>>relays document. >>>>>>>> >>>>>>>>Is this something that the working group is thinking? >>>>>>>> >>>>>>>>/Miguel >>>>>>>>-- >>>>>>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>>>>>> Jorvas, Finland >>>>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Simple mailing list >>>>>>>>Simple@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>>>> >>>>>>-- >>>>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>>>> Jorvas, Finland >>>>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>>>> >>>>> >>>>> >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>>> >>>>____________________________________________________________ >> >>___________ >> >>>_ >>> >>> >>>>This email has been scanned for all viruses by the MessageLabs Email >>>>Security System. For more information on a proactive email security >>>>service working around the clock, around the globe, visit >>>>http://www.messagelabs.com >>>>____________________________________________________________ >> >>___________ >> >>>_ >>> >>> >> >>______________________________________________________________ >>__________ >> >>>This email has been scanned for all viruses by the MessageLabs Email >>>Security System. For more information on a proactive email security >>>service working around the clock, around the globe, visit >>>http://www.messagelabs.com >>> >> >>______________________________________________________________ >>__________ >> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> >>_______________________________________________ >>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 -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 10:35:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23300; Tue, 25 Nov 2003 10:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfER-00073a-00; Tue, 25 Nov 2003 10:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfEQ-00073X-00; Tue, 25 Nov 2003 10:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfEP-0001Mb-22; Tue, 25 Nov 2003 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfDS-0001EG-Sl for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:35:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23189 for ; Tue, 25 Nov 2003 10:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfDQ-00071W-00 for simple@ietf.org; Tue, 25 Nov 2003 10:35:00 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOfDP-00071T-00 for simple@ietf.org; Tue, 25 Nov 2003 10:34:59 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFYjnG019257; Tue, 25 Nov 2003 09:34:51 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3768E.3010805@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB70118B108@esebe019.ntc.nokia.com> <3FC3240C.1050403@ericsson.com> In-Reply-To: <3FC3240C.1050403@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:34:38 -0600 Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > This proposal is an incomplete specification. Precluding support for > proxies and NAT these days seems a bad idea. If you allow to have a > collection of endpoints deployed that do not support relays, we will > definitely get problems. I think there are two sides of this. If we treat relays as an extension, then it is important that endpoints who do not know about relays can still talk to endpoints that know about and want to use relays. But it is not so important that all endpoints know how to initiate the use of relays. In the 01 draft, the use of a relay is transparent to the visitor, unless the visitor wants to use a relay of its own. I think it is reasonable to expect the relay draft to maintain that transparency. This makes it possible for an endpoint that does not know about relays to participate in a relay-hosted session. BIND does not affect this in any way. > > /Miguel > > hisham.khartabil@nokia.com wrote: > >> Hi Miguel, >> >> I don't agree with you. The relay case will be seen as an extension of >> MS(R)P and therefore all methods to support relays should be defined >> in that document. >> >> If endpoint implementers want to support relays for NAT traversal, >> then they better implement whatever is documented in the relay document. >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>> ext Miguel A. Garcia >>> Sent: 24.November.2003 20:48 >>> To: Ben Campbell >>> Cc: Simple WG >>> Subject: [Simple] BIND and relays documentation >>> >>> >>> Hi: >>> >>> A question about the recent decision to split the MSRP protocol into >>> a relay-less document and a document that details the use of relays. >>> >>> I would like to understand if the idea is to document the BIND >>> primitive in the relay-less document or in the relayful document. >>> >>> Some folks may argue that the BIND primitive is only used in the case >>> there are relays in the path, and as such, it should be documented in >>> the relays document. However, in doing so, we may risk that end >>> points will not implement the BIND primitive ever, and therefore will >>> not support the operation through relays. >>> >>> I am in favour of documenting the BIND primitive in the core MSRP >>> document, in spite that the relay operation will be described in the >>> relays document. >>> >>> Is this something that the working group is thinking? >>> >>> /Miguel >>> -- >>> Miguel-Angel Garcia Oy LM Ericsson AB >>> Jorvas, Finland >>> mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>> mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>> >>> >>> >>> _______________________________________________ >>> 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 exim@www1.ietf.org Tue Nov 25 10:36:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23347 for ; Tue, 25 Nov 2003 10:36:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfET-0001Oz-Vn for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFa5Ks005383 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfET-0001Ok-SK for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23300; Tue, 25 Nov 2003 10:35:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfER-00073a-00; Tue, 25 Nov 2003 10:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfEQ-00073X-00; Tue, 25 Nov 2003 10:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfEP-0001Mb-22; Tue, 25 Nov 2003 10:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfDS-0001EG-Sl for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:35:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23189 for ; Tue, 25 Nov 2003 10:34:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfDQ-00071W-00 for simple@ietf.org; Tue, 25 Nov 2003 10:35:00 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOfDP-00071T-00 for simple@ietf.org; Tue, 25 Nov 2003 10:34:59 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFYjnG019257; Tue, 25 Nov 2003 09:34:51 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3768E.3010805@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB70118B108@esebe019.ntc.nokia.com> <3FC3240C.1050403@ericsson.com> In-Reply-To: <3FC3240C.1050403@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:34:38 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Miguel A. Garcia wrote: > This proposal is an incomplete specification. Precluding support for > proxies and NAT these days seems a bad idea. If you allow to have a > collection of endpoints deployed that do not support relays, we will > definitely get problems. I think there are two sides of this. If we treat relays as an extension, then it is important that endpoints who do not know about relays can still talk to endpoints that know about and want to use relays. But it is not so important that all endpoints know how to initiate the use of relays. In the 01 draft, the use of a relay is transparent to the visitor, unless the visitor wants to use a relay of its own. I think it is reasonable to expect the relay draft to maintain that transparency. This makes it possible for an endpoint that does not know about relays to participate in a relay-hosted session. BIND does not affect this in any way. > > /Miguel > > hisham.khartabil@nokia.com wrote: > >> Hi Miguel, >> >> I don't agree with you. The relay case will be seen as an extension of >> MS(R)P and therefore all methods to support relays should be defined >> in that document. >> >> If endpoint implementers want to support relays for NAT traversal, >> then they better implement whatever is documented in the relay document. >> >> Regards, >> Hisham >> >> >>> -----Original Message----- >>> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>> ext Miguel A. Garcia >>> Sent: 24.November.2003 20:48 >>> To: Ben Campbell >>> Cc: Simple WG >>> Subject: [Simple] BIND and relays documentation >>> >>> >>> Hi: >>> >>> A question about the recent decision to split the MSRP protocol into >>> a relay-less document and a document that details the use of relays. >>> >>> I would like to understand if the idea is to document the BIND >>> primitive in the relay-less document or in the relayful document. >>> >>> Some folks may argue that the BIND primitive is only used in the case >>> there are relays in the path, and as such, it should be documented in >>> the relays document. However, in doing so, we may risk that end >>> points will not implement the BIND primitive ever, and therefore will >>> not support the operation through relays. >>> >>> I am in favour of documenting the BIND primitive in the core MSRP >>> document, in spite that the relay operation will be described in the >>> relays document. >>> >>> Is this something that the working group is thinking? >>> >>> /Miguel >>> -- >>> Miguel-Angel Garcia Oy LM Ericsson AB >>> Jorvas, Finland >>> mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>> mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>> >>> >>> >>> _______________________________________________ >>> 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-admin@ietf.org Tue Nov 25 10:36:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23378; Tue, 25 Nov 2003 10:36:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfFL-00074Q-00; Tue, 25 Nov 2003 10:36:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfFL-00074K-00; Tue, 25 Nov 2003 10:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfFM-0001Rz-GG; Tue, 25 Nov 2003 10:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfES-0001Of-MG for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:36:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23297 for ; Tue, 25 Nov 2003 10:35:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfEQ-00073U-00 for simple@ietf.org; Tue, 25 Nov 2003 10:36:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOfEP-00073R-00 for simple@ietf.org; Tue, 25 Nov 2003 10:36:01 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPFa0A27328 for ; Tue, 25 Nov 2003 17:36:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 17:36:00 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 17:35:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOzZ+ELIce9BsdmRc6HjPGmNTwMdQAAGxTQ To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 15:35:59.0518 (UTC) FILETIME=[D357A3E0:01C3B369] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:35:58 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 25.November.2003 17:21 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: 24.November.2003 22:38 > >>To: Jonathan Rosenberg > >>Cc: Simple WG > >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions > >> > >> > >>Jonathan Rosenberg wrote: > >> > >> > >>>This issue consumed a lot of discussion during the=20 > Minneapolis IETF. > >>> > >>>The current xcap-auth specification adds support for=20 > >> > >>exceptions within=20 > >> > >>>the applies-to statements. This allows for a way to say=20 > >> > >>that a statement=20 > >> > >>>applies to all the users in a domain or list EXCEPT the=20 > >> > >>listed set of=20 > >> > >>>users. This is useful for specifying things like "I want to grant=20 > >>>permission to everyone in dynamicsoft.com except for Bob".=20 > >> > >>Presumably=20 > >> > >>>Bob is an annoying guy and I just don't want to grant him=20 > >> > >>permission. > >> > >>>Now, a few points need to be made clear about the=20 > >> > >>exceptions processing. > >> > >>>Firstly, having things like this: > >>> > >>> > >>> > >>> > >>> sip:joe@example.com > >>> > >>> > >>> > >>>is completely useless. The reason is that it is really easy=20 > >> > >>to obtain=20 > >> > >>>new names from many namespace providers. As a result, you=20 > >> > >>may thikn you=20 > >> > >>>are blocking Joe, but he just goes off, gets a new URI from=20 > >> > >>yahoo, and=20 > >> > >>>your permission statement is useless. > >>>Indeed, the entire notion of except clauses is only useful=20 > >> > >>if you assume=20 > >> > >>>that there are cases where it is hard to obtain new=20 > >> > >>identifiers. There=20 > >> > >>>was some dispute about whether this is a good assumnption=20 > >> > >>or not. I, and=20 > >> > >>>some others, do believe that in many enterprises, it is a good=20 > >>>assumption that obtaining a new enterprise identifier is not easy. > >> > >>While agree that outside of walled-gardens your example is not very=20 > >>useful, I do think this is very useful when your applies-to=20 > >>is scoped to=20 > >>a domain. > >> > >>This is not limited to enterprise deployments. It may be true=20 > >>that some=20 > >>providers give away identities for free, it is not the case=20 > >>that _all_=20 > >>providers do this. In fact, I think the whole argument that=20 > you don't=20 > >>need exceptions becauses identities are free is bogus. > >> > >> > >>>A second point on exceptions. If an exception represents a=20 > >> > >>list, and you=20 > >> > >>>can't dereference that list, then you have to drop the=20 > >> > >>entire permission=20 > >> > >>>statement. This is to ensure privacy-safety, so that=20 > >> > >>information is not=20 > >> > >>>leaked under any failure condition. > >>> > >>>Finally, it needs to be clarified that exceptions still result in=20 > >>>additive permissions. So, for example, if I have two=20 > >> > >>staements like this: > >> > >>> > >>> example.com > >>> > >>> sip:sally@example.com > >>> > >>> > >>> > >>> > >>> > >>>and > >>> > >>> > >>> example.com > >>> > >>> sip:bob@example.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>That if EITHER Sally or Bob subscribes, they will be=20 > >> > >>granted permission=20 > >> > >>>to subscribe. Thats because, if Bob subscribes, the first policy=20 > >>>statement applies to him, resulting in his subscription=20 > >> > >>being accepted.=20 > >> > >>>If Sally subscribes, the second applies to her, and her=20 > >> > >>subscription is=20 > >> > >>>accepted. > >>> > >>>If you try and make except clauses carry across permission=20 > >> > >>statements,=20 > >> > >>>you end up in a place where these statements are no longer=20 > >> > >>additive, and=20 > >> > >>>you are not privacy safe anymore. > >>> > >>>Now, even given these clarifications, the geopriv group is=20 > >> > >>not planning=20 > >> > >>>on specifying an except condition at this time. Though they=20 > >> > >>consider it=20 > >> > >>>useful, its been ruled out of scope for the initial policy=20 > >> > >>document.=20 > >> > >>>Thus, if we wish to align, we would need to also rule it=20 > >> > >>out of scope in=20 > >> > >>>the initial version of the specification. > >>> > >>>That does not mean it could never be done; indeed, it would be my=20 > >>>proposal to more or less immediately have a draft defining it, and=20 > >>>progress this just behind the main specs. > >>> > >>>IMHO, it is worth getting alignment to let this feature=20 > >> > >>move forward in=20 > >> > >>>a separate specification, behind the main one. > >>> > >>>Comments and thoughts? > >> > >>I personally do not think we can live without exceptions,=20 > even for a=20 > >>little while. Since the additive approach does not allow me to=20 > >>explicitly black-list someone and have that override any other=20 > >>permissions, then the only way I could create a rule that allowed=20 > >>everyone from example.com except alice would be to list=20 > every single=20 > >>member of example.com explicitly. This is bad enough from a=20 > >>convenience=20 > >>perspective--but in reality it is very unlikely example.com=20 > >>will share=20 > >>its membership roster with me, so I could not do this even if=20 > >>I wanted to. > >=20 > >=20 > > The way it works today is that you have a list of=20 > presentities and a list of watchers. The list of watchers is=20 > what the issues are about. In most systems today, the list of=20 > watchers is a mirror to the list of presentities, and=20 > therefore does not include everyone is a domain.=20 > >=20 > > I think it is ok for now to give permissions to individual=20 > watchers as selected by the presentity. We are not at a stage=20 > in presence systems where we want to allow everyone at a=20 > domain to view someone's presence excepting individual x and=20 > y. But more like 15 to 20 individuals that the presentity=20 > mostly interacts with in that domain. > >=20 > > So, instead of allowing, for example, everyone at=20 > example.com except for Bob. I can pick john, alice, ben and=20 > adam from example.com that I interact with and want to allow=20 > to be my watchers, and create permissions for them. This=20 > leaves out bob along with everyone else at example.com. I=20 > think this is good enough. >=20 > So you have allowed John, Alice, Ben and Adam. That is _not_=20 > the same as=20 > "Everyone but Bob". For example, what if Carol joins example.com=20 > tomorrow. The "Allow John, Alice, Ben, and Adam" rule will=20 > not include=20 > her, but the "Everyone but Bob rule" would. Then you add a permission statement for Carol. This works. Jonathan did = not suggest throwing away exceptions indefinitely. He questioned the = usability of the first cut of xcap-auth without exceptions, and my = opinion is that it is usable in the manner I described. /Hisham >=20 > Most of the existing systems that mirror the watcher and presentity=20 > lists are single-domain systems. In an interoperable, multidomain=20 > system, I think that policy needs will quickly outstrip the=20 > expressivity=20 > of the rule language if you don't have exceptions. >=20 > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>I am willing to live with limiting exceptions expressions to=20 > >>things that=20 > >>never require external resolution. > >> > >> > >>>Thanks, > >>>Jonathan R. > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 10:37:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23414 for ; Tue, 25 Nov 2003 10:37:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfFS-0001Wv-NP for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:37:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFb6ex005870 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:37:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfFS-0001WR-CN for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23378; Tue, 25 Nov 2003 10:36:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfFL-00074Q-00; Tue, 25 Nov 2003 10:36:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfFL-00074K-00; Tue, 25 Nov 2003 10:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfFM-0001Rz-GG; Tue, 25 Nov 2003 10:37:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfES-0001Of-MG for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:36:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23297 for ; Tue, 25 Nov 2003 10:35:49 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfEQ-00073U-00 for simple@ietf.org; Tue, 25 Nov 2003 10:36:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOfEP-00073R-00 for simple@ietf.org; Tue, 25 Nov 2003 10:36:01 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPFa0A27328 for ; Tue, 25 Nov 2003 17:36:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 17:36:00 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 17:35:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 8: exceptions Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOzZ+ELIce9BsdmRc6HjPGmNTwMdQAAGxTQ To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 15:35:59.0518 (UTC) FILETIME=[D357A3E0:01C3B369] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:35:58 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 25.November.2003 17:21 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: 24.November.2003 22:38 > >>To: Jonathan Rosenberg > >>Cc: Simple WG > >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions > >> > >> > >>Jonathan Rosenberg wrote: > >> > >> > >>>This issue consumed a lot of discussion during the=20 > Minneapolis IETF. > >>> > >>>The current xcap-auth specification adds support for=20 > >> > >>exceptions within=20 > >> > >>>the applies-to statements. This allows for a way to say=20 > >> > >>that a statement=20 > >> > >>>applies to all the users in a domain or list EXCEPT the=20 > >> > >>listed set of=20 > >> > >>>users. This is useful for specifying things like "I want to grant=20 > >>>permission to everyone in dynamicsoft.com except for Bob".=20 > >> > >>Presumably=20 > >> > >>>Bob is an annoying guy and I just don't want to grant him=20 > >> > >>permission. > >> > >>>Now, a few points need to be made clear about the=20 > >> > >>exceptions processing. > >> > >>>Firstly, having things like this: > >>> > >>> > >>> > >>> > >>> sip:joe@example.com > >>> > >>> > >>> > >>>is completely useless. The reason is that it is really easy=20 > >> > >>to obtain=20 > >> > >>>new names from many namespace providers. As a result, you=20 > >> > >>may thikn you=20 > >> > >>>are blocking Joe, but he just goes off, gets a new URI from=20 > >> > >>yahoo, and=20 > >> > >>>your permission statement is useless. > >>>Indeed, the entire notion of except clauses is only useful=20 > >> > >>if you assume=20 > >> > >>>that there are cases where it is hard to obtain new=20 > >> > >>identifiers. There=20 > >> > >>>was some dispute about whether this is a good assumnption=20 > >> > >>or not. I, and=20 > >> > >>>some others, do believe that in many enterprises, it is a good=20 > >>>assumption that obtaining a new enterprise identifier is not easy. > >> > >>While agree that outside of walled-gardens your example is not very=20 > >>useful, I do think this is very useful when your applies-to=20 > >>is scoped to=20 > >>a domain. > >> > >>This is not limited to enterprise deployments. It may be true=20 > >>that some=20 > >>providers give away identities for free, it is not the case=20 > >>that _all_=20 > >>providers do this. In fact, I think the whole argument that=20 > you don't=20 > >>need exceptions becauses identities are free is bogus. > >> > >> > >>>A second point on exceptions. If an exception represents a=20 > >> > >>list, and you=20 > >> > >>>can't dereference that list, then you have to drop the=20 > >> > >>entire permission=20 > >> > >>>statement. This is to ensure privacy-safety, so that=20 > >> > >>information is not=20 > >> > >>>leaked under any failure condition. > >>> > >>>Finally, it needs to be clarified that exceptions still result in=20 > >>>additive permissions. So, for example, if I have two=20 > >> > >>staements like this: > >> > >>> > >>> example.com > >>> > >>> sip:sally@example.com > >>> > >>> > >>> > >>> > >>> > >>>and > >>> > >>> > >>> example.com > >>> > >>> sip:bob@example.com > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>That if EITHER Sally or Bob subscribes, they will be=20 > >> > >>granted permission=20 > >> > >>>to subscribe. Thats because, if Bob subscribes, the first policy=20 > >>>statement applies to him, resulting in his subscription=20 > >> > >>being accepted.=20 > >> > >>>If Sally subscribes, the second applies to her, and her=20 > >> > >>subscription is=20 > >> > >>>accepted. > >>> > >>>If you try and make except clauses carry across permission=20 > >> > >>statements,=20 > >> > >>>you end up in a place where these statements are no longer=20 > >> > >>additive, and=20 > >> > >>>you are not privacy safe anymore. > >>> > >>>Now, even given these clarifications, the geopriv group is=20 > >> > >>not planning=20 > >> > >>>on specifying an except condition at this time. Though they=20 > >> > >>consider it=20 > >> > >>>useful, its been ruled out of scope for the initial policy=20 > >> > >>document.=20 > >> > >>>Thus, if we wish to align, we would need to also rule it=20 > >> > >>out of scope in=20 > >> > >>>the initial version of the specification. > >>> > >>>That does not mean it could never be done; indeed, it would be my=20 > >>>proposal to more or less immediately have a draft defining it, and=20 > >>>progress this just behind the main specs. > >>> > >>>IMHO, it is worth getting alignment to let this feature=20 > >> > >>move forward in=20 > >> > >>>a separate specification, behind the main one. > >>> > >>>Comments and thoughts? > >> > >>I personally do not think we can live without exceptions,=20 > even for a=20 > >>little while. Since the additive approach does not allow me to=20 > >>explicitly black-list someone and have that override any other=20 > >>permissions, then the only way I could create a rule that allowed=20 > >>everyone from example.com except alice would be to list=20 > every single=20 > >>member of example.com explicitly. This is bad enough from a=20 > >>convenience=20 > >>perspective--but in reality it is very unlikely example.com=20 > >>will share=20 > >>its membership roster with me, so I could not do this even if=20 > >>I wanted to. > >=20 > >=20 > > The way it works today is that you have a list of=20 > presentities and a list of watchers. The list of watchers is=20 > what the issues are about. In most systems today, the list of=20 > watchers is a mirror to the list of presentities, and=20 > therefore does not include everyone is a domain.=20 > >=20 > > I think it is ok for now to give permissions to individual=20 > watchers as selected by the presentity. We are not at a stage=20 > in presence systems where we want to allow everyone at a=20 > domain to view someone's presence excepting individual x and=20 > y. But more like 15 to 20 individuals that the presentity=20 > mostly interacts with in that domain. > >=20 > > So, instead of allowing, for example, everyone at=20 > example.com except for Bob. I can pick john, alice, ben and=20 > adam from example.com that I interact with and want to allow=20 > to be my watchers, and create permissions for them. This=20 > leaves out bob along with everyone else at example.com. I=20 > think this is good enough. >=20 > So you have allowed John, Alice, Ben and Adam. That is _not_=20 > the same as=20 > "Everyone but Bob". For example, what if Carol joins example.com=20 > tomorrow. The "Allow John, Alice, Ben, and Adam" rule will=20 > not include=20 > her, but the "Everyone but Bob rule" would. Then you add a permission statement for Carol. This works. Jonathan did = not suggest throwing away exceptions indefinitely. He questioned the = usability of the first cut of xcap-auth without exceptions, and my = opinion is that it is usable in the manner I described. /Hisham >=20 > Most of the existing systems that mirror the watcher and presentity=20 > lists are single-domain systems. In an interoperable, multidomain=20 > system, I think that policy needs will quickly outstrip the=20 > expressivity=20 > of the rule language if you don't have exceptions. >=20 > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>I am willing to live with limiting exceptions expressions to=20 > >>things that=20 > >>never require external resolution. > >> > >> > >>>Thanks, > >>>Jonathan R. > >> > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 10:37:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23444; Tue, 25 Nov 2003 10:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfGN-00075Q-00; Tue, 25 Nov 2003 10:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfGN-00075N-00; Tue, 25 Nov 2003 10:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfGM-0001j9-Pb; Tue, 25 Nov 2003 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfG8-0001fl-2g for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23431 for ; Tue, 25 Nov 2003 10:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfG5-000750-00 for simple@ietf.org; Tue, 25 Nov 2003 10:37:45 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOfG4-00074x-00 for simple@ietf.org; Tue, 25 Nov 2003 10:37:44 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFbanG019515; Tue, 25 Nov 2003 09:37:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3773A.8070201@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Miguel.A.Garcia@ericsson.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:37:30 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > We will support relays for NAT traversal, in a separate document. But having half the solution documented is a separate I-D is not appropriate, IMO. I am not sure I follow your meaning. Do you mean (1) having the relay specification spread between drafts (BIND in one, the rest in the other) is not appropriate, or (2) Splitting the total solution into two drafts, one specifying a point-to-point solution, and the other specifying a relay extension is inappropriate? > > /Hisham > > >>-----Original Message----- >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: 25.November.2003 11:43 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >> >>This proposal is an incomplete specification. Precluding support for >>proxies and NAT these days seems a bad idea. If you allow to have a >>collection of endpoints deployed that do not support relays, we will >>definitely get problems. >> >>/Miguel >> >>hisham.khartabil@nokia.com wrote: >> >> >>>Hi Miguel, >>> >>>I don't agree with you. The relay case will be seen as an >> >>extension of MS(R)P and therefore all methods to support >>relays should be defined in that document. >> >>>If endpoint implementers want to support relays for NAT >> >>traversal, then they better implement whatever is documented >>in the relay document. >> >>>Regards, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Miguel A. Garcia >>>>Sent: 24.November.2003 20:48 >>>>To: Ben Campbell >>>>Cc: Simple WG >>>>Subject: [Simple] BIND and relays documentation >>>> >>>> >>>>Hi: >>>> >>>>A question about the recent decision to split the MSRP >>>>protocol into a >>>>relay-less document and a document that details the use of relays. >>>> >>>>I would like to understand if the idea is to document the >>>>BIND primitive >>>>in the relay-less document or in the relayful document. >>>> >>>>Some folks may argue that the BIND primitive is only used >> >>in the case >> >>>>there are relays in the path, and as such, it should be >> >>documented in >> >>>>the relays document. However, in doing so, we may risk that >>>>end points >>>>will not implement the BIND primitive ever, and therefore will not >>>>support the operation through relays. >>>> >>>>I am in favour of documenting the BIND primitive in the core MSRP >>>>document, in spite that the relay operation will be >> >>described in the >> >>>>relays document. >>>> >>>>Is this something that the working group is thinking? >>>> >>>>/Miguel >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 10:38:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23481 for ; Tue, 25 Nov 2003 10:38:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfGR-0001o5-Uf for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:38:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFc7b8006935 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfGR-0001nk-DX for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:38:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23444; Tue, 25 Nov 2003 10:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfGN-00075Q-00; Tue, 25 Nov 2003 10:38:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfGN-00075N-00; Tue, 25 Nov 2003 10:38:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfGM-0001j9-Pb; Tue, 25 Nov 2003 10:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfG8-0001fl-2g for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:37:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23431 for ; Tue, 25 Nov 2003 10:37:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfG5-000750-00 for simple@ietf.org; Tue, 25 Nov 2003 10:37:45 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOfG4-00074x-00 for simple@ietf.org; Tue, 25 Nov 2003 10:37:44 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPFbanG019515; Tue, 25 Nov 2003 09:37:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3773A.8070201@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: Miguel.A.Garcia@ericsson.com, simple@ietf.org Subject: Re: [Simple] BIND and relays documentation References: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797435@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 09:37:30 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > We will support relays for NAT traversal, in a separate document. But having half the solution documented is a separate I-D is not appropriate, IMO. I am not sure I follow your meaning. Do you mean (1) having the relay specification spread between drafts (BIND in one, the rest in the other) is not appropriate, or (2) Splitting the total solution into two drafts, one specifying a point-to-point solution, and the other specifying a relay extension is inappropriate? > > /Hisham > > >>-----Original Message----- >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] >>Sent: 25.November.2003 11:43 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] BIND and relays documentation >> >> >>This proposal is an incomplete specification. Precluding support for >>proxies and NAT these days seems a bad idea. If you allow to have a >>collection of endpoints deployed that do not support relays, we will >>definitely get problems. >> >>/Miguel >> >>hisham.khartabil@nokia.com wrote: >> >> >>>Hi Miguel, >>> >>>I don't agree with you. The relay case will be seen as an >> >>extension of MS(R)P and therefore all methods to support >>relays should be defined in that document. >> >>>If endpoint implementers want to support relays for NAT >> >>traversal, then they better implement whatever is documented >>in the relay document. >> >>>Regards, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Miguel A. Garcia >>>>Sent: 24.November.2003 20:48 >>>>To: Ben Campbell >>>>Cc: Simple WG >>>>Subject: [Simple] BIND and relays documentation >>>> >>>> >>>>Hi: >>>> >>>>A question about the recent decision to split the MSRP >>>>protocol into a >>>>relay-less document and a document that details the use of relays. >>>> >>>>I would like to understand if the idea is to document the >>>>BIND primitive >>>>in the relay-less document or in the relayful document. >>>> >>>>Some folks may argue that the BIND primitive is only used >> >>in the case >> >>>>there are relays in the path, and as such, it should be >> >>documented in >> >>>>the relays document. However, in doing so, we may risk that >>>>end points >>>>will not implement the BIND primitive ever, and therefore will not >>>>support the operation through relays. >>>> >>>>I am in favour of documenting the BIND primitive in the core MSRP >>>>document, in spite that the relay operation will be >> >>described in the >> >>>>relays document. >>>> >>>>Is this something that the working group is thinking? >>>> >>>>/Miguel >>>>-- >>>>Miguel-Angel Garcia Oy LM Ericsson AB >>>> Jorvas, Finland >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >>>> >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>-- >>Miguel-Angel Garcia Oy LM Ericsson AB >> Jorvas, Finland >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 10:41:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23633; Tue, 25 Nov 2003 10:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfKD-0007AB-00; Tue, 25 Nov 2003 10:42:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfKD-0007A8-00; Tue, 25 Nov 2003 10:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfKD-0002GT-Fb; Tue, 25 Nov 2003 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfJv-0002G9-OD for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:41:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23623 for ; Tue, 25 Nov 2003 10:41:23 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfJo-00079d-00 for simple@ietf.org; Tue, 25 Nov 2003 10:41:36 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOfJn-00079F-00 for simple@ietf.org; Tue, 25 Nov 2003 10:41:35 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPFfY601177 for ; Tue, 25 Nov 2003 17:41:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 17:41:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 17:41:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179743F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzahilfmwu94McQbeyD/O//dvuGwAAGUjQ To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 15:41:32.0851 (UTC) FILETIME=[9A063830:01C3B36A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:41:32 +0200 Content-Transfer-Encoding: quoted-printable I read points 1 and 2 the same. In any case, I meant the former. /Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 25.November.2003 17:38 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Miguel.A.Garcia@ericsson.com; simple@ietf.org > Subject: Re: [Simple] BIND and relays documentation >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > We will support relays for NAT traversal, in a separate=20 > document. But having half the solution documented is a=20 > separate I-D is not appropriate, IMO. >=20 > I am not sure I follow your meaning. Do you mean (1) having the relay=20 > specification spread between drafts (BIND in one, the rest in=20 > the other)=20 > is not appropriate, or (2) Splitting the total solution into=20 > two drafts,=20 > one specifying a point-to-point solution, and the other specifying a=20 > relay extension is inappropriate? >=20 > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>Sent: 25.November.2003 11:43 > >>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org > >>Subject: Re: [Simple] BIND and relays documentation > >> > >> > >>This proposal is an incomplete specification. Precluding=20 > support for=20 > >>proxies and NAT these days seems a bad idea. If you allow to have a=20 > >>collection of endpoints deployed that do not support=20 > relays, we will=20 > >>definitely get problems. > >> > >>/Miguel > >> > >>hisham.khartabil@nokia.com wrote: > >> > >> > >>>Hi Miguel, > >>> > >>>I don't agree with you. The relay case will be seen as an=20 > >> > >>extension of MS(R)P and therefore all methods to support=20 > >>relays should be defined in that document. > >> > >>>If endpoint implementers want to support relays for NAT=20 > >> > >>traversal, then they better implement whatever is documented=20 > >>in the relay document. > >> > >>>Regards, > >>>Hisham > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: simple-admin@ietf.org=20 > >> > >>[mailto:simple-admin@ietf.org]On Behalf Of > >> > >>>>ext Miguel A. Garcia > >>>>Sent: 24.November.2003 20:48 > >>>>To: Ben Campbell > >>>>Cc: Simple WG > >>>>Subject: [Simple] BIND and relays documentation > >>>> > >>>> > >>>>Hi: > >>>> > >>>>A question about the recent decision to split the MSRP=20 > >>>>protocol into a=20 > >>>>relay-less document and a document that details the use of relays. > >>>> > >>>>I would like to understand if the idea is to document the=20 > >>>>BIND primitive=20 > >>>>in the relay-less document or in the relayful document. > >>>> > >>>>Some folks may argue that the BIND primitive is only used=20 > >> > >>in the case=20 > >> > >>>>there are relays in the path, and as such, it should be=20 > >> > >>documented in=20 > >> > >>>>the relays document. However, in doing so, we may risk that=20 > >>>>end points=20 > >>>>will not implement the BIND primitive ever, and therefore=20 > will not=20 > >>>>support the operation through relays. > >>>> > >>>>I am in favour of documenting the BIND primitive in the core MSRP=20 > >>>>document, in spite that the relay operation will be=20 > >> > >>described in the=20 > >> > >>>>relays document. > >>>> > >>>>Is this something that the working group is thinking? > >>>> > >>>>/Miguel > >>>>--=20 > >>>>Miguel-Angel Garcia Oy LM Ericsson AB > >>>> Jorvas, Finland > >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>--=20 > >>Miguel-Angel Garcia Oy LM Ericsson AB > >> Jorvas, Finland > >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >> > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 10:42:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23681 for ; Tue, 25 Nov 2003 10:42:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfKG-0002IT-KL for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPFg4wT008823 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 10:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfKG-0002IE-Gx for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 10:42:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23633; Tue, 25 Nov 2003 10:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfKD-0007AB-00; Tue, 25 Nov 2003 10:42:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOfKD-0007A8-00; Tue, 25 Nov 2003 10:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfKD-0002GT-Fb; Tue, 25 Nov 2003 10:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOfJv-0002G9-OD for simple@optimus.ietf.org; Tue, 25 Nov 2003 10:41:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23623 for ; Tue, 25 Nov 2003 10:41:23 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOfJo-00079d-00 for simple@ietf.org; Tue, 25 Nov 2003 10:41:36 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOfJn-00079F-00 for simple@ietf.org; Tue, 25 Nov 2003 10:41:35 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPFfY601177 for ; Tue, 25 Nov 2003 17:41:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 17:41:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 17:41:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] BIND and relays documentation Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179743F@esebe019.ntc.nokia.com> Thread-Topic: [Simple] BIND and relays documentation Thread-Index: AcOzahilfmwu94McQbeyD/O//dvuGwAAGUjQ To: Cc: , X-OriginalArrivalTime: 25 Nov 2003 15:41:32.0851 (UTC) FILETIME=[9A063830:01C3B36A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:41:32 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I read points 1 and 2 the same. In any case, I meant the former. /Hisham > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 25.November.2003 17:38 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: Miguel.A.Garcia@ericsson.com; simple@ietf.org > Subject: Re: [Simple] BIND and relays documentation >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > We will support relays for NAT traversal, in a separate=20 > document. But having half the solution documented is a=20 > separate I-D is not appropriate, IMO. >=20 > I am not sure I follow your meaning. Do you mean (1) having the relay=20 > specification spread between drafts (BIND in one, the rest in=20 > the other)=20 > is not appropriate, or (2) Splitting the total solution into=20 > two drafts,=20 > one specifying a point-to-point solution, and the other specifying a=20 > relay extension is inappropriate? >=20 > >=20 > > /Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: ext Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] > >>Sent: 25.November.2003 11:43 > >>To: Khartabil Hisham (NMP-MSW/Helsinki) > >>Cc: bcampbell@dynamicsoft.com; simple@ietf.org > >>Subject: Re: [Simple] BIND and relays documentation > >> > >> > >>This proposal is an incomplete specification. Precluding=20 > support for=20 > >>proxies and NAT these days seems a bad idea. If you allow to have a=20 > >>collection of endpoints deployed that do not support=20 > relays, we will=20 > >>definitely get problems. > >> > >>/Miguel > >> > >>hisham.khartabil@nokia.com wrote: > >> > >> > >>>Hi Miguel, > >>> > >>>I don't agree with you. The relay case will be seen as an=20 > >> > >>extension of MS(R)P and therefore all methods to support=20 > >>relays should be defined in that document. > >> > >>>If endpoint implementers want to support relays for NAT=20 > >> > >>traversal, then they better implement whatever is documented=20 > >>in the relay document. > >> > >>>Regards, > >>>Hisham > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: simple-admin@ietf.org=20 > >> > >>[mailto:simple-admin@ietf.org]On Behalf Of > >> > >>>>ext Miguel A. Garcia > >>>>Sent: 24.November.2003 20:48 > >>>>To: Ben Campbell > >>>>Cc: Simple WG > >>>>Subject: [Simple] BIND and relays documentation > >>>> > >>>> > >>>>Hi: > >>>> > >>>>A question about the recent decision to split the MSRP=20 > >>>>protocol into a=20 > >>>>relay-less document and a document that details the use of relays. > >>>> > >>>>I would like to understand if the idea is to document the=20 > >>>>BIND primitive=20 > >>>>in the relay-less document or in the relayful document. > >>>> > >>>>Some folks may argue that the BIND primitive is only used=20 > >> > >>in the case=20 > >> > >>>>there are relays in the path, and as such, it should be=20 > >> > >>documented in=20 > >> > >>>>the relays document. However, in doing so, we may risk that=20 > >>>>end points=20 > >>>>will not implement the BIND primitive ever, and therefore=20 > will not=20 > >>>>support the operation through relays. > >>>> > >>>>I am in favour of documenting the BIND primitive in the core MSRP=20 > >>>>document, in spite that the relay operation will be=20 > >> > >>described in the=20 > >> > >>>>relays document. > >>>> > >>>>Is this something that the working group is thinking? > >>>> > >>>>/Miguel > >>>>--=20 > >>>>Miguel-Angel Garcia Oy LM Ericsson AB > >>>> Jorvas, Finland > >>>>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>>>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>--=20 > >>Miguel-Angel Garcia Oy LM Ericsson AB > >> Jorvas, Finland > >>mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 > >>mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 > >> > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 12:09:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27508; Tue, 25 Nov 2003 12:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOghW-0001Cb-00; Tue, 25 Nov 2003 12:10:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOghW-0001CY-00; Tue, 25 Nov 2003 12:10:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOghN-0001Dx-CK; Tue, 25 Nov 2003 12:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgge-0001CZ-Q5 for simple@optimus.ietf.org; Tue, 25 Nov 2003 12:09:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27464 for ; Tue, 25 Nov 2003 12:09:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOggd-0001Bh-00 for simple@ietf.org; Tue, 25 Nov 2003 12:09:15 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOggc-0001Be-00 for simple@ietf.org; Tue, 25 Nov 2003 12:09:14 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPH9DV22602; Tue, 25 Nov 2003 18:09:13 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPH9Cm22505; Tue, 25 Nov 2003 18:09:12 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 18:08:54 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0483@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'hisham.khartabil@nokia.com'" , jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 18:07:05 +0100 Hi hisham, We had a long discussion on the different authentication mechanisms and our conclusion was that it is technical very difficult to differentiate the different levels of authentication. You can easily see our shift over the past few drafts in the Geopriv working group. The differentiation between tls, http digest, etc. as authentication mechanism is of little value. I guess Jonathan's proposal is to remove these authentication mechanisms and to replace them with - anonymous and - everything else is authenticated (i.e., identities are provided within the rule). I guess that this also goes inline with your proposal. Ciao Hannes > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, November 24, 2003 12:54 PM > To: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication > > > Can the user at least have a say in accepting or rejecting > the subscription based on the availability of any > authentication type. Eg: A user can reject subscriptions that > are not authenticated in any way and accept subscriptions > that are authenticated, regardless of authentication type. > > Regards, > Hisham > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > ext Jonathan Rosenberg > > Sent: 24.November.2003 08:13 > > To: Simple WG > > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > > > > > Folks, > > > > Currently, xcap-auth defines an authentication condition. > This allows > > you to decide whether to accept or reject a subscription > based on the > > type of authentication used in the SUBSCRIBE request. > > > > The geopriv policy specification currently has no such mechanism. > > > > This was discussed during the geopriv meeting in > Minneapolis. If you > > think about it for a bit, its not clear how this would actually get > > used. Remember, it is end users that will set these policies. What > > kind of meaningful information can be provided to a user about the > > differences between p-asserted-id and sip-identity and digest > > authentication? What would make a user give permission for > > one type or > > authentication, and not another? Practically speaking, it > doesnt seem > > like its easy to use at all. > > > > As a result, I would propose to remove the authentication condition > > from xcap-auth. > > > > Comments? > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 12:10:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27534 for ; Tue, 25 Nov 2003 12:10:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOghY-0001FP-LB for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 12:10:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHACV3004789 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 12:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOghY-0001FA-C4 for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:10:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27508; Tue, 25 Nov 2003 12:09:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOghW-0001Cb-00; Tue, 25 Nov 2003 12:10:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOghW-0001CY-00; Tue, 25 Nov 2003 12:10:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOghN-0001Dx-CK; Tue, 25 Nov 2003 12:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgge-0001CZ-Q5 for simple@optimus.ietf.org; Tue, 25 Nov 2003 12:09:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27464 for ; Tue, 25 Nov 2003 12:09:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOggd-0001Bh-00 for simple@ietf.org; Tue, 25 Nov 2003 12:09:15 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOggc-0001Be-00 for simple@ietf.org; Tue, 25 Nov 2003 12:09:14 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPH9DV22602; Tue, 25 Nov 2003 18:09:13 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPH9Cm22505; Tue, 25 Nov 2003 18:09:12 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 18:08:54 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0483@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'hisham.khartabil@nokia.com'" , jdrosen@dynamicsoft.com, simple@ietf.org Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 18:07:05 +0100 Hi hisham, We had a long discussion on the different authentication mechanisms and our conclusion was that it is technical very difficult to differentiate the different levels of authentication. You can easily see our shift over the past few drafts in the Geopriv working group. The differentiation between tls, http digest, etc. as authentication mechanism is of little value. I guess Jonathan's proposal is to remove these authentication mechanisms and to replace them with - anonymous and - everything else is authenticated (i.e., identities are provided within the rule). I guess that this also goes inline with your proposal. Ciao Hannes > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Monday, November 24, 2003 12:54 PM > To: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication > > > Can the user at least have a say in accepting or rejecting > the subscription based on the availability of any > authentication type. Eg: A user can reject subscriptions that > are not authenticated in any way and accept subscriptions > that are authenticated, regardless of authentication type. > > Regards, > Hisham > > > -----Original Message----- > > From: simple-admin@ietf.org > [mailto:simple-admin@ietf.org]On Behalf Of > > ext Jonathan Rosenberg > > Sent: 24.November.2003 08:13 > > To: Simple WG > > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > > > > > Folks, > > > > Currently, xcap-auth defines an authentication condition. > This allows > > you to decide whether to accept or reject a subscription > based on the > > type of authentication used in the SUBSCRIBE request. > > > > The geopriv policy specification currently has no such mechanism. > > > > This was discussed during the geopriv meeting in > Minneapolis. If you > > think about it for a bit, its not clear how this would actually get > > used. Remember, it is end users that will set these policies. What > > kind of meaningful information can be provided to a user about the > > differences between p-asserted-id and sip-identity and digest > > authentication? What would make a user give permission for > > one type or > > authentication, and not another? Practically speaking, it > doesnt seem > > like its easy to use at all. > > > > As a result, I would propose to remove the authentication condition > > from xcap-auth. > > > > Comments? > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 12:25:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28422; Tue, 25 Nov 2003 12:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgwt-0001Yx-00; Tue, 25 Nov 2003 12:26:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgwt-0001Yu-00; Tue, 25 Nov 2003 12:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgwr-0002uF-RK; Tue, 25 Nov 2003 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgwc-0002ss-1I for simple@optimus.ietf.org; Tue, 25 Nov 2003 12:25:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28381 for ; Tue, 25 Nov 2003 12:25:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgwa-0001Xk-00 for simple@ietf.org; Tue, 25 Nov 2003 12:25:44 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOgwZ-0001Xh-00 for simple@ietf.org; Tue, 25 Nov 2003 12:25:44 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPHPhV04745; Tue, 25 Nov 2003 18:25:43 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPHPgm02970; Tue, 25 Nov 2003 18:25:42 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 18:25:25 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0485@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 3: spheres MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 18:23:37 +0100 Hi Jonathan, I would like to provide some history for including the sphere in our current geopriv authz draft. We had a very long discussion on how to enforce repeatable time windows to implement a functionality of the following style: I don't want my collegues to see my location information if I am not at work. For some jobs you are able to translate this fact by listing your regular working hours 9am to 5pm. Obviously, this does not work for all jobs and has some further technical problems. Recognizing these limitations Henning proposed an alternative which I personally found very useful. Are you suggesting to drop it or should it be replaced by something else? How do you express policies similar to the one listed above? Ciao Hannes > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, November 24, 2003 7:09 AM > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 3: spheres > > > Folks, > > In the current geopriv policy document, there is a condition called > "sphere". This allows a presentity to tell the server that > this policy > statement only applies if the current sphere of the presentity has > some value. Sphere refers to an RPID element (which, afaik, is not in > the current rpid document, and would need to be added for this to be > useful) that describes my current situation - whether I am at > work, at > home, sleeping, etc. Its a dynamic context, for which my > privacy rules > vary as the context varies. > > As an example, I could define a policy thusly: > > > example.com > work > > > > > > > and: > > > example.com > home > > > > basic > > > This would have the effect of showing my example.com colleauges my > full presence when I'm at work, but only my basic status when > I'm at home. > > So, the question is, do we adopt this in xcap-auth? > > I am inclined to NOT adopt it, and indeed, to encourage geopriv to > remove it, in order to reduce scope. > > Comments? > > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 12:26:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28450 for ; Tue, 25 Nov 2003 12:26:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgwv-0002vY-P7 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 12:26:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHQ5p1011251 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 12:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgwv-0002vO-K4 for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:26:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28422; Tue, 25 Nov 2003 12:25:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgwt-0001Yx-00; Tue, 25 Nov 2003 12:26:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOgwt-0001Yu-00; Tue, 25 Nov 2003 12:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgwr-0002uF-RK; Tue, 25 Nov 2003 12:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgwc-0002ss-1I for simple@optimus.ietf.org; Tue, 25 Nov 2003 12:25:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28381 for ; Tue, 25 Nov 2003 12:25:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgwa-0001Xk-00 for simple@ietf.org; Tue, 25 Nov 2003 12:25:44 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOgwZ-0001Xh-00 for simple@ietf.org; Tue, 25 Nov 2003 12:25:44 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPHPhV04745; Tue, 25 Nov 2003 18:25:43 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPHPgm02970; Tue, 25 Nov 2003 18:25:42 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Nov 2003 18:25:25 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0485@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 3: spheres MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 18:23:37 +0100 Hi Jonathan, I would like to provide some history for including the sphere in our current geopriv authz draft. We had a very long discussion on how to enforce repeatable time windows to implement a functionality of the following style: I don't want my collegues to see my location information if I am not at work. For some jobs you are able to translate this fact by listing your regular working hours 9am to 5pm. Obviously, this does not work for all jobs and has some further technical problems. Recognizing these limitations Henning proposed an alternative which I personally found very useful. Are you suggesting to drop it or should it be replaced by something else? How do you express policies similar to the one listed above? Ciao Hannes > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, November 24, 2003 7:09 AM > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 3: spheres > > > Folks, > > In the current geopriv policy document, there is a condition called > "sphere". This allows a presentity to tell the server that > this policy > statement only applies if the current sphere of the presentity has > some value. Sphere refers to an RPID element (which, afaik, is not in > the current rpid document, and would need to be added for this to be > useful) that describes my current situation - whether I am at > work, at > home, sleeping, etc. Its a dynamic context, for which my > privacy rules > vary as the context varies. > > As an example, I could define a policy thusly: > > > example.com > work > > > > > > > and: > > > example.com > home > > > > basic > > > This would have the effect of showing my example.com colleauges my > full presence when I'm at work, but only my basic status when > I'm at home. > > So, the question is, do we adopt this in xcap-auth? > > I am inclined to NOT adopt it, and indeed, to encourage geopriv to > remove it, in order to reduce scope. > > Comments? > > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 12:34:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28778; Tue, 25 Nov 2003 12:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOh5c-0001jf-00; Tue, 25 Nov 2003 12:35:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOh5b-0001jc-00; Tue, 25 Nov 2003 12:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh5a-0003bg-Kw; Tue, 25 Nov 2003 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh4l-0003ac-Ld for simple@optimus.ietf.org; Tue, 25 Nov 2003 12:34:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28760 for ; Tue, 25 Nov 2003 12:33:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOh4j-0001jJ-00 for simple@ietf.org; Tue, 25 Nov 2003 12:34:09 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOh4j-0001jG-00 for simple@ietf.org; Tue, 25 Nov 2003 12:34:09 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPHY7620769 for ; Tue, 25 Nov 2003 19:34:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 19:34:06 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 19:34:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 19:34:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797440@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOzduDvj/OTVpazRLWwiTN+DSEJ2wAA0pjA To: , , X-OriginalArrivalTime: 25 Nov 2003 17:34:06.0435 (UTC) FILETIME=[53795B30:01C3B37A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 19:34:06 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 25.November.2003 19:07 > To: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Hi hisham,=20 >=20 > We had a long discussion on the different authentication=20 > mechanisms and our > conclusion was that it is technical very difficult to=20 > differentiate the > different levels of authentication. You can easily see our=20 > shift over the > past few drafts in the Geopriv working group.=20 >=20 > The differentiation between tls, http digest, etc. as authentication > mechanism is of little value. I guess Jonathan's proposal is=20 > to remove these > authentication mechanisms and to replace them with=20 > - anonymous and=20 > - everything else is authenticated (i.e., identities are=20 > provided within the > rule). >=20 > I guess that this also goes inline with your proposal.=20 You seem to describe it that way. I'm happy with that. /Hisham >=20 > Ciao > Hannes=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, November 24, 2003 12:54 PM > > To: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication > >=20 > >=20 > > Can the user at least have a say in accepting or rejecting=20 > > the subscription based on the availability of any=20 > > authentication type. Eg: A user can reject subscriptions that=20 > > are not authenticated in any way and accept subscriptions=20 > > that are authenticated, regardless of authentication type. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of > > > ext Jonathan Rosenberg > > > Sent: 24.November.2003 08:13 > > > To: Simple WG > > > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > >=20 > > >=20 > > > Folks, > > >=20 > > > Currently, xcap-auth defines an authentication condition.=20 > > This allows=20 > > > you to decide whether to accept or reject a subscription=20 > > based on the=20 > > > type of authentication used in the SUBSCRIBE request. > > >=20 > > > The geopriv policy specification currently has no such mechanism. > > >=20 > > > This was discussed during the geopriv meeting in=20 > > Minneapolis. If you=20 > > > think about it for a bit, its not clear how this would=20 > actually get=20 > > > used. Remember, it is end users that will set these=20 > policies. What=20 > > > kind of meaningful information can be provided to a user=20 > about the=20 > > > differences between p-asserted-id and sip-identity and digest=20 > > > authentication? What would make a user give permission for=20 > > > one type or=20 > > > authentication, and not another? Practically speaking, it=20 > > doesnt seem=20 > > > like its easy to use at all. > > >=20 > > > As a result, I would propose to remove the authentication=20 > condition=20 > > > from xcap-auth. > > >=20 > > > Comments? > > >=20 > > > -Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ=20 > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 12:35:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28812 for ; Tue, 25 Nov 2003 12:35:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh5e-0003cd-Ai for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 12:35:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPHZ6K8013917 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 12:35:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh5e-0003cO-7G for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 12:35:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28778; Tue, 25 Nov 2003 12:34:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOh5c-0001jf-00; Tue, 25 Nov 2003 12:35:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOh5b-0001jc-00; Tue, 25 Nov 2003 12:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh5a-0003bg-Kw; Tue, 25 Nov 2003 12:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOh4l-0003ac-Ld for simple@optimus.ietf.org; Tue, 25 Nov 2003 12:34:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28760 for ; Tue, 25 Nov 2003 12:33:56 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOh4j-0001jJ-00 for simple@ietf.org; Tue, 25 Nov 2003 12:34:09 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOh4j-0001jG-00 for simple@ietf.org; Tue, 25 Nov 2003 12:34:09 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPHY7620769 for ; Tue, 25 Nov 2003 19:34:07 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 19:34:06 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 19:34:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 19:34:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797440@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOzduDvj/OTVpazRLWwiTN+DSEJ2wAA0pjA To: , , X-OriginalArrivalTime: 25 Nov 2003 17:34:06.0435 (UTC) FILETIME=[53795B30:01C3B37A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 19:34:06 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: 25.November.2003 19:07 > To: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; > simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Hi hisham,=20 >=20 > We had a long discussion on the different authentication=20 > mechanisms and our > conclusion was that it is technical very difficult to=20 > differentiate the > different levels of authentication. You can easily see our=20 > shift over the > past few drafts in the Geopriv working group.=20 >=20 > The differentiation between tls, http digest, etc. as authentication > mechanism is of little value. I guess Jonathan's proposal is=20 > to remove these > authentication mechanisms and to replace them with=20 > - anonymous and=20 > - everything else is authenticated (i.e., identities are=20 > provided within the > rule). >=20 > I guess that this also goes inline with your proposal.=20 You seem to describe it that way. I'm happy with that. /Hisham >=20 > Ciao > Hannes=20 >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > > Sent: Monday, November 24, 2003 12:54 PM > > To: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication > >=20 > >=20 > > Can the user at least have a say in accepting or rejecting=20 > > the subscription based on the availability of any=20 > > authentication type. Eg: A user can reject subscriptions that=20 > > are not authenticated in any way and accept subscriptions=20 > > that are authenticated, regardless of authentication type. > >=20 > > Regards, > > Hisham > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org=20 > > [mailto:simple-admin@ietf.org]On Behalf Of > > > ext Jonathan Rosenberg > > > Sent: 24.November.2003 08:13 > > > To: Simple WG > > > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > >=20 > > >=20 > > > Folks, > > >=20 > > > Currently, xcap-auth defines an authentication condition.=20 > > This allows=20 > > > you to decide whether to accept or reject a subscription=20 > > based on the=20 > > > type of authentication used in the SUBSCRIBE request. > > >=20 > > > The geopriv policy specification currently has no such mechanism. > > >=20 > > > This was discussed during the geopriv meeting in=20 > > Minneapolis. If you=20 > > > think about it for a bit, its not clear how this would=20 > actually get=20 > > > used. Remember, it is end users that will set these=20 > policies. What=20 > > > kind of meaningful information can be provided to a user=20 > about the=20 > > > differences between p-asserted-id and sip-identity and digest=20 > > > authentication? What would make a user give permission for=20 > > > one type or=20 > > > authentication, and not another? Practically speaking, it=20 > > doesnt seem=20 > > > like its easy to use at all. > > >=20 > > > As a result, I would propose to remove the authentication=20 > condition=20 > > > from xcap-auth. > > >=20 > > > Comments? > > >=20 > > > -Jonathan R. > > > --=20 > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Chief Technology Officer Parsippany, NJ=20 > > 07054-2711 > > > dynamicsoft > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 14:19:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03226; Tue, 25 Nov 2003 14:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOijF-0003Qz-00; Tue, 25 Nov 2003 14:20:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOijE-0003Qw-00; Tue, 25 Nov 2003 14:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOijD-0001Es-Gh; Tue, 25 Nov 2003 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiil-0001DC-QV for simple@optimus.ietf.org; Tue, 25 Nov 2003 14:19:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03133 for ; Tue, 25 Nov 2003 14:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiij-0003Nv-00 for simple@ietf.org; Tue, 25 Nov 2003 14:19:33 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOiii-0003NM-00 for simple@ietf.org; Tue, 25 Nov 2003 14:19:32 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAPJJ6ca022320; Tue, 25 Nov 2003 14:19:06 -0500 (EST) Message-ID: <3FC3AB24.90003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events References: <475FF955A05DD411980D00508B6D5FB00439EF29@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF29@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:19:00 -0500 Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Two further comments: > > 1) At the San Francisco meeting between 3GPP and IETF, back in > January, we had a long discussion of what IETF meant by SHOULD, and > the view from at least some of the area directors was that > effectively they expected to see the SHOULD implemented, and I > believe Jonathan put forward the view that allowable reasons for > not implementing the SHOULD are best reflected in the specification > as further text. Should we therefore add this to bugs list for > something that requires additional text in RFC 3265? I think thats a good idea, yes. I've added it to the database: http://bugs.sipit.net/sipwg/show_bug.cgi?id=741 > > 2) You mention that this was really intended at INVITE requests. > The text as written also applies to REFER dialogs. It could, though I think its most useful for INVITE. > With respect to > SUBSCRIBE dialogs, is not useful to indicate in a SUBSCRIBE > response to event A that event package B and C are supported? That is probably useful, yes. > Is it > not the case that presence servers supporting the "presence" event, > probably (i.e. SHOULD strength) also support the "presence.winfo" > event template. We have never made that a requirement anywhere. I'm not sure its IETF's job to do that. Would it be useful to indicate this support, given > that the support of one package is only a SHOULD, given the support > of the other, or do you have some other way of determining this > information? Thus user A subscribing for the presence of user B > would get an indication of whether user A could see other users, > e.g. user B, watching him. I agree that learning other packages that are supported would be useful. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 14:20:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03267 for ; Tue, 25 Nov 2003 14:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOijI-0001G5-IV for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 14:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJK8SY004831 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 14:20:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOijI-0001Fq-7S for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03226; Tue, 25 Nov 2003 14:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOijF-0003Qz-00; Tue, 25 Nov 2003 14:20:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOijE-0003Qw-00; Tue, 25 Nov 2003 14:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOijD-0001Es-Gh; Tue, 25 Nov 2003 14:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiil-0001DC-QV for simple@optimus.ietf.org; Tue, 25 Nov 2003 14:19:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03133 for ; Tue, 25 Nov 2003 14:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOiij-0003Nv-00 for simple@ietf.org; Tue, 25 Nov 2003 14:19:33 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOiii-0003NM-00 for simple@ietf.org; Tue, 25 Nov 2003 14:19:32 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAPJJ6ca022320; Tue, 25 Nov 2003 14:19:06 -0500 (EST) Message-ID: <3FC3AB24.90003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events References: <475FF955A05DD411980D00508B6D5FB00439EF29@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF29@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:19:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > Two further comments: > > 1) At the San Francisco meeting between 3GPP and IETF, back in > January, we had a long discussion of what IETF meant by SHOULD, and > the view from at least some of the area directors was that > effectively they expected to see the SHOULD implemented, and I > believe Jonathan put forward the view that allowable reasons for > not implementing the SHOULD are best reflected in the specification > as further text. Should we therefore add this to bugs list for > something that requires additional text in RFC 3265? I think thats a good idea, yes. I've added it to the database: http://bugs.sipit.net/sipwg/show_bug.cgi?id=741 > > 2) You mention that this was really intended at INVITE requests. > The text as written also applies to REFER dialogs. It could, though I think its most useful for INVITE. > With respect to > SUBSCRIBE dialogs, is not useful to indicate in a SUBSCRIBE > response to event A that event package B and C are supported? That is probably useful, yes. > Is it > not the case that presence servers supporting the "presence" event, > probably (i.e. SHOULD strength) also support the "presence.winfo" > event template. We have never made that a requirement anywhere. I'm not sure its IETF's job to do that. Would it be useful to indicate this support, given > that the support of one package is only a SHOULD, given the support > of the other, or do you have some other way of determining this > information? Thus user A subscribing for the presence of user B > would get an indication of whether user A could see other users, > e.g. user B, watching him. I agree that learning other packages that are supported would be useful. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 14:29:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03730; Tue, 25 Nov 2003 14:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOist-0003bC-00; Tue, 25 Nov 2003 14:30:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOiss-0003b9-00; Tue, 25 Nov 2003 14:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiss-0001iN-LU; Tue, 25 Nov 2003 14:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOisO-0001h4-Pq for simple@optimus.ietf.org; Tue, 25 Nov 2003 14:29:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03704 for ; Tue, 25 Nov 2003 14:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOisL-0003aW-00 for simple@ietf.org; Tue, 25 Nov 2003 14:29:29 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOisL-0003Zw-00 for simple@ietf.org; Tue, 25 Nov 2003 14:29:29 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAPJT3ca022327; Tue, 25 Nov 2003 14:29:03 -0500 (EST) Message-ID: <3FC3AD78.1030808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nadezhda Fedorova CC: simple@ietf.org Subject: Re: [Simple] Questions about SIMPLE References: <5514680559.20031122152824@war.ru> In-Reply-To: <5514680559.20031122152824@war.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:28:56 -0500 Content-Transfer-Encoding: 7bit inline. Nadezhda Fedorova wrote: > Hello all, > > Could you please answer some questions about SIMPLE? > I need to make IM System based on SIP and SIMPLE, so I've read a lot of > documents about SIMPLE and didn't find answers to them. > Please answer me if you can. > > Here are the questions: > > 1. Is it possible to use resource lists (RL) not only for defining list of my > buddies and subscribing to events from them, but e.g. > for inviting many people to a dialog, > or for sending a message to all of them simultaneously? That is just now under consideration. The xcap-list spec was recently updated to allow for this possibility: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt although there is no specifics for message or invite. This is also intimately related to the recent exploders work: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-01.txt http://www.ietf.org/internet-drafts/draft-camarillo-sipping-explode-method-00.txt http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-solution-00.txt > > If it is, then what must be the behaviour of UAC and UAS when > UAC sends a message to all buddies from his RL and some of > buddies are offline and some online? Unless the server explicitly supports the notion of messaging to a group, the server would return a 405 indicating that this method is not allowed on that resource. > > 2. Are there any common mechanisms (rules) for sending offline messages > (I mean rules for sending a message to a user when he is > offline)? No standards work has been done in this area at this time. We do have some requirements that were written about it some time ago: http://www.jdrosen.net/papers/draft-rosenberg-simple-messaging-requirements-00.txt > > 3. How can I SUBSCRIBE to all events from a resource? > That is not supported. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 14:30:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03784 for ; Tue, 25 Nov 2003 14:30:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOisw-0001ji-MG for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 14:30:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPJU6jK006668 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 14:30:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOisw-0001jT-HU for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 14:30:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03730; Tue, 25 Nov 2003 14:29:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOist-0003bC-00; Tue, 25 Nov 2003 14:30:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOiss-0003b9-00; Tue, 25 Nov 2003 14:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOiss-0001iN-LU; Tue, 25 Nov 2003 14:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOisO-0001h4-Pq for simple@optimus.ietf.org; Tue, 25 Nov 2003 14:29:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03704 for ; Tue, 25 Nov 2003 14:29:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOisL-0003aW-00 for simple@ietf.org; Tue, 25 Nov 2003 14:29:29 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOisL-0003Zw-00 for simple@ietf.org; Tue, 25 Nov 2003 14:29:29 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAPJT3ca022327; Tue, 25 Nov 2003 14:29:03 -0500 (EST) Message-ID: <3FC3AD78.1030808@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nadezhda Fedorova CC: simple@ietf.org Subject: Re: [Simple] Questions about SIMPLE References: <5514680559.20031122152824@war.ru> In-Reply-To: <5514680559.20031122152824@war.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:28:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Nadezhda Fedorova wrote: > Hello all, > > Could you please answer some questions about SIMPLE? > I need to make IM System based on SIP and SIMPLE, so I've read a lot of > documents about SIMPLE and didn't find answers to them. > Please answer me if you can. > > Here are the questions: > > 1. Is it possible to use resource lists (RL) not only for defining list of my > buddies and subscribing to events from them, but e.g. > for inviting many people to a dialog, > or for sending a message to all of them simultaneously? That is just now under consideration. The xcap-list spec was recently updated to allow for this possibility: http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-list-usage-01.txt although there is no specifics for message or invite. This is also intimately related to the recent exploders work: http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-01.txt http://www.ietf.org/internet-drafts/draft-camarillo-sipping-explode-method-00.txt http://www.ietf.org/internet-drafts/draft-camarillo-sipping-exploders-solution-00.txt > > If it is, then what must be the behaviour of UAC and UAS when > UAC sends a message to all buddies from his RL and some of > buddies are offline and some online? Unless the server explicitly supports the notion of messaging to a group, the server would return a 405 indicating that this method is not allowed on that resource. > > 2. Are there any common mechanisms (rules) for sending offline messages > (I mean rules for sending a message to a user when he is > offline)? No standards work has been done in this area at this time. We do have some requirements that were written about it some time ago: http://www.jdrosen.net/papers/draft-rosenberg-simple-messaging-requirements-00.txt > > 3. How can I SUBSCRIBE to all events from a resource? > That is not supported. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 15:05:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05795; Tue, 25 Nov 2003 15:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjRj-0004TG-00; Tue, 25 Nov 2003 15:06:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjRi-0004TD-00; Tue, 25 Nov 2003 15:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjRh-0004Gr-CU; Tue, 25 Nov 2003 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjRZ-0004GP-3p for simple@optimus.ietf.org; Tue, 25 Nov 2003 15:05:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05759 for ; Tue, 25 Nov 2003 15:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjRV-0004Sl-00 for simple@ietf.org; Tue, 25 Nov 2003 15:05:49 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOjRV-0004Rx-00 for simple@ietf.org; Tue, 25 Nov 2003 15:05:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAPK5Id15014; Tue, 25 Nov 2003 14:05:18 -0600 Subject: Re: [Simple] xcap/geopriv alignment, issue 1: conditions From: Robert Sparks To: Jonathan Rosenberg Cc: Simple WG In-Reply-To: <3FC19D75.3040800@dynamicsoft.com> References: <3FC19D75.3040800@dynamicsoft.com> Content-Type: text/plain Message-Id: <1069790716.955.24.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:05:16 -0600 Content-Transfer-Encoding: 7bit I agree that moving the conditional from an accept-if into the applies-to tag is the right thing to do. There is at least one ramification that needs to be carefully documented if we do this. There needs to be a way to say things like "I'll accept (whatever) if it is authenticated using either Digest or an S/MIME signature." In xcap-auth-01, I think this was acheivable with multiple accept-if's inside a permission (but am not sure where I got this idea - accept-if is missing from the schema). With this proposed change, we will have to either have to have multiple permissions (one that accepts if digest and another that accepts if s/mime) or add an OR function to the list of things in applies-to. I can accept having to state this using multiple permissions. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 15:06:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05875 for ; Tue, 25 Nov 2003 15:06:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjRo-0004Hr-01 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 15:06:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPK67hY016473 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 15:06:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjRn-0004Hc-41 for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:06:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05795; Tue, 25 Nov 2003 15:05:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjRj-0004TG-00; Tue, 25 Nov 2003 15:06:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjRi-0004TD-00; Tue, 25 Nov 2003 15:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjRh-0004Gr-CU; Tue, 25 Nov 2003 15:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjRZ-0004GP-3p for simple@optimus.ietf.org; Tue, 25 Nov 2003 15:05:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05759 for ; Tue, 25 Nov 2003 15:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjRV-0004Sl-00 for simple@ietf.org; Tue, 25 Nov 2003 15:05:49 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOjRV-0004Rx-00 for simple@ietf.org; Tue, 25 Nov 2003 15:05:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAPK5Id15014; Tue, 25 Nov 2003 14:05:18 -0600 Subject: Re: [Simple] xcap/geopriv alignment, issue 1: conditions From: Robert Sparks To: Jonathan Rosenberg Cc: Simple WG In-Reply-To: <3FC19D75.3040800@dynamicsoft.com> References: <3FC19D75.3040800@dynamicsoft.com> Content-Type: text/plain Message-Id: <1069790716.955.24.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 14:05:16 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree that moving the conditional from an accept-if into the applies-to tag is the right thing to do. There is at least one ramification that needs to be carefully documented if we do this. There needs to be a way to say things like "I'll accept (whatever) if it is authenticated using either Digest or an S/MIME signature." In xcap-auth-01, I think this was acheivable with multiple accept-if's inside a permission (but am not sure where I got this idea - accept-if is missing from the schema). With this proposed change, we will have to either have to have multiple permissions (one that accepts if digest and another that accepts if s/mime) or add an OR function to the list of things in applies-to. I can accept having to state this using multiple permissions. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 15:24:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07441; Tue, 25 Nov 2003 15:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjk9-0004vv-00; Tue, 25 Nov 2003 15:25:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjk8-0004vp-00; Tue, 25 Nov 2003 15:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjk6-0005lk-Ce; Tue, 25 Nov 2003 15:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjj9-0005kV-2l for simple@optimus.ietf.org; Tue, 25 Nov 2003 15:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07426 for ; Tue, 25 Nov 2003 15:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj7-0004ui-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:01 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj7-0004ue-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:01 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKO0609757; Tue, 25 Nov 2003 21:24:00 +0100 (MET) Received: from joe ([139.25.62.25]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKNxm08728; Tue, 25 Nov 2003 21:23:59 +0100 (MET) From: "Hannes Tschofenig" To: "'Ben Campbell'" , "Jonathan Rosenberg" Cc: "Simple WG" Subject: RE: [Simple] xcap/geopriv alignment issue 5: permission data types Message-ID: <000301c3b391$e7408160$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3FC26FB5.4090105@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 21:22:52 +0100 Content-Transfer-Encoding: quoted-printable Hi ben,=20 You raised an interesting issue addressing rule permission combining. = You might want to take a look at our geopriv authz draft. =20 The draft describes how permissions are combined for some cases. = However, as noted in the geopriv wg meeting there are still some technical issues to achieve the expected behavior. We pointed to a subset of issues (i.e., default behavior) in our presentation at http://www.tschofenig.com/geopriv/IETF58/Geopriv_policies_ietf58.ppt = (slide 22/23).=20 In a more sophisticated example you might even have to define a lattice. = You can find an example in Section 7.4 of our draft.=20 My conclusion is that we have to look carefully at examples to verify = the result. In Jonathan's example below you need to make sure that you = carefully define what 'true' and 'false' means. The same is true for values like accuracy.=20 Ciao Hannes > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > Sent: Montag, 24. November 2003 21:53 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] xcap/geopriv alignment issue 5:=20 > permission data types >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > Folks, > >=20 > > In the current xcap-auth spec, there is a big assumption that each > > permission (show-element, show-namespace, accept,=20 > accept-if, etc.) is=20 > > basically a token datatype. If multiple statements apply,=20 > the overall=20 > > permissions are the union across these tokens. > >=20 > > However, in the geopriv spec, they define some additional=20 > data types. > > Namely, they define boolean and integer. Combining=20 > operations are then=20 > > also defined for these types (logical OR for booleans, MAX=20 > operator for=20 > > integers). > >=20 > > As an example, lets say you have a permission called "accuracy": > >=20 > > > > sip:fluffy@cisco.com > > > >=20 > > 10 > >=20 > >=20 > >=20 > > > > cisco.com > > > >=20 > > 5 > >=20 > >=20 > > This would have the effect of granting an accuracy of 5 to=20 > everyone in > > Cisco, excepting fluffy who would get 10. > >=20 > > The question, then, is whether or not to define/allow these=20 > data types > > and also define their combining rules. NOTE WELL - you=20 > would need to=20 > > properly define your permissions such that, for an integer,=20 > a larger=20 > > value is always more permissive. For booleans, TRUE would=20 > need to always=20 > > be more permissive. >=20 > I am having trouble understanding how this is any different than=20 > previously proposed, at least in the case of your example.=20 > Previously,=20 > this simply meant 2 rules matched fluffy--so if 10 is more permissive=20 > than 5, he effectively has 10. Would this proposal allow a=20 > combination=20 > rule that would give fluffy 15? >=20 >=20 > >=20 > > A related issue is whether or not to convert some of our current > > permissions from tokens to booleans. In particular, the accept,=20 > > all-content and show-note permissions would become=20 > booleans. The benefit=20 > > of that is that you can explicitly say no by setting a=20 > value to false: > >=20 > > > > sip:schulzrinne@columbia.edu > > > >=20 > > false > >=20 > >=20 > > would explicitly reject any subscriptions from Henning. >=20 > Hmm. I assume that if another matching rule sayd=20 > true=20 > then true would win, right? Otherwise, we no longer have additive=20 > permissions. >=20 >=20 > >=20 > > So, the question is whether or not to (1) add support for=20 > integral and > > boolean data types, and (2) convert the all-content, show-note and=20 > > accept permissions to booleans. I believe that, independent=20 > of geopriv=20 > > alignment, these are both good ideas and we should do it. > >=20 > > Comments? > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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-admin@ietf.org Tue Nov 25 15:24:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07438; Tue, 25 Nov 2003 15:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjk8-0004vs-00; Tue, 25 Nov 2003 15:25:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjk8-0004vo-00; Tue, 25 Nov 2003 15:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjk5-0005lc-DZ; Tue, 25 Nov 2003 15:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjj7-0005kQ-Ra for simple@optimus.ietf.org; Tue, 25 Nov 2003 15:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07423 for ; Tue, 25 Nov 2003 15:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj6-0004ub-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:00 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj6-0004uW-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:00 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKNxV27747; Tue, 25 Nov 2003 21:23:59 +0100 (MET) Received: from joe ([139.25.62.25]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKNsm08706; Tue, 25 Nov 2003 21:23:54 +0100 (MET) From: "Hannes Tschofenig" To: , Cc: , Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: <000201c3b391$e66a93c0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797432@esebe019.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 21:21:58 +0100 Content-Transfer-Encoding: quoted-printable Hi ben,=20 This issue is not about the absence of authentication. It is only about = a specific mechanism. An example:=20 Would you like to indicate policies stating that you show information X = to henning if he authenticated himself using tls but not using http digest. = If an identity is provided then it is always assumed that you performed authentication (otherwise it is anonymous). Without cryptographic authentication you could provide any identity (i.e., identity spoofing = is very simple).=20 btw, a small note. Stating tls as authentication mechanism is actually = wrong since you have to indicate which protocol was used within the tls = handshake, e.g.,=20 - Kerberos - Unilateral pk-based authentication - Mutual pk-based authentication - Shared secret authentication - strong-password based authentication using srp ciao hannes > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Dienstag, 25. November 2003 09:20 > To: bcampbell@dynamicsoft.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 24.November.2003 23:00 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication > >=20 > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > > > Can the user at least have a say in accepting or rejecting > > the subscription based on the availability of any > > authentication type. Eg: A user can reject subscriptions that=20 > > are not authenticated in any way and accept subscriptions=20 > > that are authenticated, regardless of authentication type. > >=20 > > In the absence of _some_ authentication, what is the value of having > > authorization policies in the first place? They have no=20 > > meaning if you=20 > > cannot put some degree of trust in the requestor identity. > >=20 > > I think the email world has proven to us how useful it is to > > authorize=20 > > on un-authenticated headers. How useful is a spam filter that=20 > > relies on=20 > > the From header? >=20 > Either I'm missing your point, or you missed mine. All I said=20 > was that the user should be able to reject subscriptions if=20 > they are not authenticated (authentication method is irrelevant). >=20 > /Hisham >=20 > >=20 > > >=20 > > > Regards, > > > Hisham > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: simple-admin@ietf.org > > [mailto:simple-admin@ietf.org]On Behalf Of > > >>ext Jonathan Rosenberg > > >>Sent: 24.November.2003 08:13 > > >>To: Simple WG > > >>Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > >> > > >> > > >>Folks, > > >> > > >>Currently, xcap-auth defines an authentication condition. > > This allows > > >>you to decide whether to accept or reject a subscription > > based on the > > >>type of authentication used in the SUBSCRIBE request. > > >> > > >>The geopriv policy specification currently has no such mechanism. > > >> > > >>This was discussed during the geopriv meeting in > > Minneapolis. If you > > >>think about it for a bit, its not clear how this would=20 > actually get > > >>used. Remember, it is end users that will set these=20 > policies. What=20 > > >>kind of meaningful information can be provided to a user=20 > about the=20 > > >>differences between p-asserted-id and sip-identity and digest=20 > > >>authentication? What would make a user give permission for=20 > > >>one type or=20 > > >>authentication, and not another? Practically speaking, it=20 > > doesnt seem > > >>like its easy to use at all. > > >> > > >>As a result, I would propose to remove the authentication=20 > condition > > >>from xcap-auth. > > >> > > >>Comments? > > >> > > >>-Jonathan R. > > >>--=20 > > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > >>Chief Technology Officer Parsippany, NJ=20 > > 07054-2711 > > >>dynamicsoft > > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > >>http://www.jdrosen.net PHONE: (973) 952-5000 > > >>http://www.dynamicsoft.com > > >> > > >> > > >> > > >>_______________________________________________ > > >>Simple mailing list > > >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > >=20 >=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 exim@www1.ietf.org Tue Nov 25 15:25:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07540 for ; Tue, 25 Nov 2003 15:25:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkB-0005nN-5Z for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 15:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKP7G7022271 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 15:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkA-0005n8-W4 for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:25:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07441; Tue, 25 Nov 2003 15:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjk9-0004vv-00; Tue, 25 Nov 2003 15:25:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjk8-0004vp-00; Tue, 25 Nov 2003 15:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjk6-0005lk-Ce; Tue, 25 Nov 2003 15:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjj9-0005kV-2l for simple@optimus.ietf.org; Tue, 25 Nov 2003 15:24:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07426 for ; Tue, 25 Nov 2003 15:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj7-0004ui-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:01 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj7-0004ue-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:01 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKO0609757; Tue, 25 Nov 2003 21:24:00 +0100 (MET) Received: from joe ([139.25.62.25]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKNxm08728; Tue, 25 Nov 2003 21:23:59 +0100 (MET) From: "Hannes Tschofenig" To: "'Ben Campbell'" , "Jonathan Rosenberg" Cc: "Simple WG" Subject: RE: [Simple] xcap/geopriv alignment issue 5: permission data types Message-ID: <000301c3b391$e7408160$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3FC26FB5.4090105@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 21:22:52 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi ben,=20 You raised an interesting issue addressing rule permission combining. = You might want to take a look at our geopriv authz draft. =20 The draft describes how permissions are combined for some cases. = However, as noted in the geopriv wg meeting there are still some technical issues to achieve the expected behavior. We pointed to a subset of issues (i.e., default behavior) in our presentation at http://www.tschofenig.com/geopriv/IETF58/Geopriv_policies_ietf58.ppt = (slide 22/23).=20 In a more sophisticated example you might even have to define a lattice. = You can find an example in Section 7.4 of our draft.=20 My conclusion is that we have to look carefully at examples to verify = the result. In Jonathan's example below you need to make sure that you = carefully define what 'true' and 'false' means. The same is true for values like accuracy.=20 Ciao Hannes > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > Sent: Montag, 24. November 2003 21:53 > To: Jonathan Rosenberg > Cc: Simple WG > Subject: Re: [Simple] xcap/geopriv alignment issue 5:=20 > permission data types >=20 >=20 > Jonathan Rosenberg wrote: >=20 > > Folks, > >=20 > > In the current xcap-auth spec, there is a big assumption that each > > permission (show-element, show-namespace, accept,=20 > accept-if, etc.) is=20 > > basically a token datatype. If multiple statements apply,=20 > the overall=20 > > permissions are the union across these tokens. > >=20 > > However, in the geopriv spec, they define some additional=20 > data types. > > Namely, they define boolean and integer. Combining=20 > operations are then=20 > > also defined for these types (logical OR for booleans, MAX=20 > operator for=20 > > integers). > >=20 > > As an example, lets say you have a permission called "accuracy": > >=20 > > > > sip:fluffy@cisco.com > > > >=20 > > 10 > >=20 > >=20 > >=20 > > > > cisco.com > > > >=20 > > 5 > >=20 > >=20 > > This would have the effect of granting an accuracy of 5 to=20 > everyone in > > Cisco, excepting fluffy who would get 10. > >=20 > > The question, then, is whether or not to define/allow these=20 > data types > > and also define their combining rules. NOTE WELL - you=20 > would need to=20 > > properly define your permissions such that, for an integer,=20 > a larger=20 > > value is always more permissive. For booleans, TRUE would=20 > need to always=20 > > be more permissive. >=20 > I am having trouble understanding how this is any different than=20 > previously proposed, at least in the case of your example.=20 > Previously,=20 > this simply meant 2 rules matched fluffy--so if 10 is more permissive=20 > than 5, he effectively has 10. Would this proposal allow a=20 > combination=20 > rule that would give fluffy 15? >=20 >=20 > >=20 > > A related issue is whether or not to convert some of our current > > permissions from tokens to booleans. In particular, the accept,=20 > > all-content and show-note permissions would become=20 > booleans. The benefit=20 > > of that is that you can explicitly say no by setting a=20 > value to false: > >=20 > > > > sip:schulzrinne@columbia.edu > > > >=20 > > false > >=20 > >=20 > > would explicitly reject any subscriptions from Henning. >=20 > Hmm. I assume that if another matching rule sayd=20 > true=20 > then true would win, right? Otherwise, we no longer have additive=20 > permissions. >=20 >=20 > >=20 > > So, the question is whether or not to (1) add support for=20 > integral and > > boolean data types, and (2) convert the all-content, show-note and=20 > > accept permissions to booleans. I believe that, independent=20 > of geopriv=20 > > alignment, these are both good ideas and we should do it. > >=20 > > Comments? > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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 exim@www1.ietf.org Tue Nov 25 15:25:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07555 for ; Tue, 25 Nov 2003 15:25:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkB-0005nf-HB for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 15:25:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKP7Gg022289 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 15:25:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjkB-0005nO-Ct for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 15:25:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07438; Tue, 25 Nov 2003 15:24:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjk8-0004vs-00; Tue, 25 Nov 2003 15:25:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOjk8-0004vo-00; Tue, 25 Nov 2003 15:25:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjk5-0005lc-DZ; Tue, 25 Nov 2003 15:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjj7-0005kQ-Ra for simple@optimus.ietf.org; Tue, 25 Nov 2003 15:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07423 for ; Tue, 25 Nov 2003 15:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj6-0004ub-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:00 -0500 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx with esmtp (Exim 4.12) id 1AOjj6-0004uW-00 for simple@ietf.org; Tue, 25 Nov 2003 15:24:00 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKNxV27747; Tue, 25 Nov 2003 21:23:59 +0100 (MET) Received: from joe ([139.25.62.25]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAPKNsm08706; Tue, 25 Nov 2003 21:23:54 +0100 (MET) From: "Hannes Tschofenig" To: , Cc: , Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: <000201c3b391$e66a93c0$010aa8c0@joe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797432@esebe019.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 21:21:58 +0100 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi ben,=20 This issue is not about the absence of authentication. It is only about = a specific mechanism. An example:=20 Would you like to indicate policies stating that you show information X = to henning if he authenticated himself using tls but not using http digest. = If an identity is provided then it is always assumed that you performed authentication (otherwise it is anonymous). Without cryptographic authentication you could provide any identity (i.e., identity spoofing = is very simple).=20 btw, a small note. Stating tls as authentication mechanism is actually = wrong since you have to indicate which protocol was used within the tls = handshake, e.g.,=20 - Kerberos - Unilateral pk-based authentication - Mutual pk-based authentication - Shared secret authentication - strong-password based authentication using srp ciao hannes > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]=20 > Sent: Dienstag, 25. November 2003 09:20 > To: bcampbell@dynamicsoft.com > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 24.November.2003 23:00 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication > >=20 > >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > > > Can the user at least have a say in accepting or rejecting > > the subscription based on the availability of any > > authentication type. Eg: A user can reject subscriptions that=20 > > are not authenticated in any way and accept subscriptions=20 > > that are authenticated, regardless of authentication type. > >=20 > > In the absence of _some_ authentication, what is the value of having > > authorization policies in the first place? They have no=20 > > meaning if you=20 > > cannot put some degree of trust in the requestor identity. > >=20 > > I think the email world has proven to us how useful it is to > > authorize=20 > > on un-authenticated headers. How useful is a spam filter that=20 > > relies on=20 > > the From header? >=20 > Either I'm missing your point, or you missed mine. All I said=20 > was that the user should be able to reject subscriptions if=20 > they are not authenticated (authentication method is irrelevant). >=20 > /Hisham >=20 > >=20 > > >=20 > > > Regards, > > > Hisham > > >=20 > > >=20 > > >>-----Original Message----- > > >>From: simple-admin@ietf.org > > [mailto:simple-admin@ietf.org]On Behalf Of > > >>ext Jonathan Rosenberg > > >>Sent: 24.November.2003 08:13 > > >>To: Simple WG > > >>Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > >> > > >> > > >>Folks, > > >> > > >>Currently, xcap-auth defines an authentication condition. > > This allows > > >>you to decide whether to accept or reject a subscription > > based on the > > >>type of authentication used in the SUBSCRIBE request. > > >> > > >>The geopriv policy specification currently has no such mechanism. > > >> > > >>This was discussed during the geopriv meeting in > > Minneapolis. If you > > >>think about it for a bit, its not clear how this would=20 > actually get > > >>used. Remember, it is end users that will set these=20 > policies. What=20 > > >>kind of meaningful information can be provided to a user=20 > about the=20 > > >>differences between p-asserted-id and sip-identity and digest=20 > > >>authentication? What would make a user give permission for=20 > > >>one type or=20 > > >>authentication, and not another? Practically speaking, it=20 > > doesnt seem > > >>like its easy to use at all. > > >> > > >>As a result, I would propose to remove the authentication=20 > condition > > >>from xcap-auth. > > >> > > >>Comments? > > >> > > >>-Jonathan R. > > >>--=20 > > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > >>Chief Technology Officer Parsippany, NJ=20 > > 07054-2711 > > >>dynamicsoft > > >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > >>http://www.jdrosen.net PHONE: (973) 952-5000 > > >>http://www.dynamicsoft.com > > >> > > >> > > >> > > >>_______________________________________________ > > >>Simple mailing list > > >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > >> > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > >=20 >=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-admin@ietf.org Tue Nov 25 16:07:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10352; Tue, 25 Nov 2003 16:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkPp-0006LV-00; Tue, 25 Nov 2003 16:08:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOkPo-0006LS-00; Tue, 25 Nov 2003 16:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkPg-0000x9-VM; Tue, 25 Nov 2003 16:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkPE-0000qP-I3 for simple@optimus.ietf.org; Tue, 25 Nov 2003 16:07:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10265 for ; Tue, 25 Nov 2003 16:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkPC-0006JU-00 for simple@ietf.org; Tue, 25 Nov 2003 16:07:30 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOkPC-0006JP-00 for simple@ietf.org; Tue, 25 Nov 2003 16:07:30 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPL7MnG047376; Tue, 25 Nov 2003 15:07:22 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3C480.5080908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 15:07:12 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 25.November.2003 17:21 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: jdrosen@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >> >> >>hisham.khartabil@nokia.com wrote: >> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Ben Campbell >>>>Sent: 24.November.2003 22:38 >>>>To: Jonathan Rosenberg >>>>Cc: Simple WG >>>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>>> >>>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>> >>>>>This issue consumed a lot of discussion during the >> >>Minneapolis IETF. >> >>>>>The current xcap-auth specification adds support for >>>> >>>>exceptions within >>>> >>>> >>>>>the applies-to statements. This allows for a way to say >>>> >>>>that a statement >>>> >>>> >>>>>applies to all the users in a domain or list EXCEPT the >>>> >>>>listed set of >>>> >>>> >>>>>users. This is useful for specifying things like "I want to grant >>>>>permission to everyone in dynamicsoft.com except for Bob". >>>> >>>>Presumably >>>> >>>> >>>>>Bob is an annoying guy and I just don't want to grant him >>>> >>>>permission. >>>> >>>> >>>>>Now, a few points need to be made clear about the >>>> >>>>exceptions processing. >>>> >>>> >>>>>Firstly, having things like this: >>>>> >>>>> >>>>> >>>>> >>>>> sip:joe@example.com >>>>> >>>>> >>>>> >>>>>is completely useless. The reason is that it is really easy >>>> >>>>to obtain >>>> >>>> >>>>>new names from many namespace providers. As a result, you >>>> >>>>may thikn you >>>> >>>> >>>>>are blocking Joe, but he just goes off, gets a new URI from >>>> >>>>yahoo, and >>>> >>>> >>>>>your permission statement is useless. >>>>>Indeed, the entire notion of except clauses is only useful >>>> >>>>if you assume >>>> >>>> >>>>>that there are cases where it is hard to obtain new >>>> >>>>identifiers. There >>>> >>>> >>>>>was some dispute about whether this is a good assumnption >>>> >>>>or not. I, and >>>> >>>> >>>>>some others, do believe that in many enterprises, it is a good >>>>>assumption that obtaining a new enterprise identifier is not easy. >>>> >>>>While agree that outside of walled-gardens your example is not very >>>>useful, I do think this is very useful when your applies-to >>>>is scoped to >>>>a domain. >>>> >>>>This is not limited to enterprise deployments. It may be true >>>>that some >>>>providers give away identities for free, it is not the case >>>>that _all_ >>>>providers do this. In fact, I think the whole argument that >> >>you don't >> >>>>need exceptions becauses identities are free is bogus. >>>> >>>> >>>> >>>>>A second point on exceptions. If an exception represents a >>>> >>>>list, and you >>>> >>>> >>>>>can't dereference that list, then you have to drop the >>>> >>>>entire permission >>>> >>>> >>>>>statement. This is to ensure privacy-safety, so that >>>> >>>>information is not >>>> >>>> >>>>>leaked under any failure condition. >>>>> >>>>>Finally, it needs to be clarified that exceptions still result in >>>>>additive permissions. So, for example, if I have two >>>> >>>>staements like this: >>>> >>>> >>>>> >>>>> example.com >>>>> >>>>> sip:sally@example.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>and >>>>> >>>>> >>>>> example.com >>>>> >>>>> sip:bob@example.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>That if EITHER Sally or Bob subscribes, they will be >>>> >>>>granted permission >>>> >>>> >>>>>to subscribe. Thats because, if Bob subscribes, the first policy >>>>>statement applies to him, resulting in his subscription >>>> >>>>being accepted. >>>> >>>> >>>>>If Sally subscribes, the second applies to her, and her >>>> >>>>subscription is >>>> >>>> >>>>>accepted. >>>>> >>>>>If you try and make except clauses carry across permission >>>> >>>>statements, >>>> >>>> >>>>>you end up in a place where these statements are no longer >>>> >>>>additive, and >>>> >>>> >>>>>you are not privacy safe anymore. >>>>> >>>>>Now, even given these clarifications, the geopriv group is >>>> >>>>not planning >>>> >>>> >>>>>on specifying an except condition at this time. Though they >>>> >>>>consider it >>>> >>>> >>>>>useful, its been ruled out of scope for the initial policy >>>> >>>>document. >>>> >>>> >>>>>Thus, if we wish to align, we would need to also rule it >>>> >>>>out of scope in >>>> >>>> >>>>>the initial version of the specification. >>>>> >>>>>That does not mean it could never be done; indeed, it would be my >>>>>proposal to more or less immediately have a draft defining it, and >>>>>progress this just behind the main specs. >>>>> >>>>>IMHO, it is worth getting alignment to let this feature >>>> >>>>move forward in >>>> >>>> >>>>>a separate specification, behind the main one. >>>>> >>>>>Comments and thoughts? >>>> >>>>I personally do not think we can live without exceptions, >> >>even for a >> >>>>little while. Since the additive approach does not allow me to >>>>explicitly black-list someone and have that override any other >>>>permissions, then the only way I could create a rule that allowed >>>>everyone from example.com except alice would be to list >> >>every single >> >>>>member of example.com explicitly. This is bad enough from a >>>>convenience >>>>perspective--but in reality it is very unlikely example.com >>>>will share >>>>its membership roster with me, so I could not do this even if >>>>I wanted to. >>> >>> >>>The way it works today is that you have a list of >> >>presentities and a list of watchers. The list of watchers is >>what the issues are about. In most systems today, the list of >>watchers is a mirror to the list of presentities, and >>therefore does not include everyone is a domain. >> >>>I think it is ok for now to give permissions to individual >> >>watchers as selected by the presentity. We are not at a stage >>in presence systems where we want to allow everyone at a >>domain to view someone's presence excepting individual x and >>y. But more like 15 to 20 individuals that the presentity >>mostly interacts with in that domain. >> >>>So, instead of allowing, for example, everyone at >> >>example.com except for Bob. I can pick john, alice, ben and >>adam from example.com that I interact with and want to allow >>to be my watchers, and create permissions for them. This >>leaves out bob along with everyone else at example.com. I >>think this is good enough. >> >>So you have allowed John, Alice, Ben and Adam. That is _not_ >>the same as >>"Everyone but Bob". For example, what if Carol joins example.com >>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will >>not include >>her, but the "Everyone but Bob rule" would. > > > Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > That assumes you know about Carol. My point is, these two cases are not the same thing. You might be able to simulate something like exceptions by doing this, if and only if you have full knowledge of the membership of example.com. I suspect that will commonly be false. > /Hisham > > >>Most of the existing systems that mirror the watcher and presentity >>lists are single-domain systems. In an interoperable, multidomain >>system, I think that policy needs will quickly outstrip the >>expressivity >>of the rule language if you don't have exceptions. >> >> >>>Regards, >>>Hisham >>> >>> >>> >>>>I am willing to live with limiting exceptions expressions to >>>>things that >>>>never require external resolution. >>>> >>>> >>>> >>>>>Thanks, >>>>>Jonathan R. >>>> >>>> >>>> >>>>_______________________________________________ >>>>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 exim@www1.ietf.org Tue Nov 25 16:08:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10448 for ; Tue, 25 Nov 2003 16:08:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkPt-0000yf-F8 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 16:08:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPL8DUY003751 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 16:08:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkPr-0000yQ-Fc for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 16:08:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10352; Tue, 25 Nov 2003 16:07:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkPp-0006LV-00; Tue, 25 Nov 2003 16:08:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOkPo-0006LS-00; Tue, 25 Nov 2003 16:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkPg-0000x9-VM; Tue, 25 Nov 2003 16:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkPE-0000qP-I3 for simple@optimus.ietf.org; Tue, 25 Nov 2003 16:07:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10265 for ; Tue, 25 Nov 2003 16:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkPC-0006JU-00 for simple@ietf.org; Tue, 25 Nov 2003 16:07:30 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOkPC-0006JP-00 for simple@ietf.org; Tue, 25 Nov 2003 16:07:30 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAPL7MnG047376; Tue, 25 Nov 2003 15:07:22 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC3C480.5080908@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 15:07:12 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 25.November.2003 17:21 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: jdrosen@dynamicsoft.com; simple@ietf.org >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >> >> >>hisham.khartabil@nokia.com wrote: >> >>>>-----Original Message----- >>>>From: simple-admin@ietf.org >> >>[mailto:simple-admin@ietf.org]On Behalf Of >> >>>>ext Ben Campbell >>>>Sent: 24.November.2003 22:38 >>>>To: Jonathan Rosenberg >>>>Cc: Simple WG >>>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>>> >>>> >>>>Jonathan Rosenberg wrote: >>>> >>>> >>>> >>>>>This issue consumed a lot of discussion during the >> >>Minneapolis IETF. >> >>>>>The current xcap-auth specification adds support for >>>> >>>>exceptions within >>>> >>>> >>>>>the applies-to statements. This allows for a way to say >>>> >>>>that a statement >>>> >>>> >>>>>applies to all the users in a domain or list EXCEPT the >>>> >>>>listed set of >>>> >>>> >>>>>users. This is useful for specifying things like "I want to grant >>>>>permission to everyone in dynamicsoft.com except for Bob". >>>> >>>>Presumably >>>> >>>> >>>>>Bob is an annoying guy and I just don't want to grant him >>>> >>>>permission. >>>> >>>> >>>>>Now, a few points need to be made clear about the >>>> >>>>exceptions processing. >>>> >>>> >>>>>Firstly, having things like this: >>>>> >>>>> >>>>> >>>>> >>>>> sip:joe@example.com >>>>> >>>>> >>>>> >>>>>is completely useless. The reason is that it is really easy >>>> >>>>to obtain >>>> >>>> >>>>>new names from many namespace providers. As a result, you >>>> >>>>may thikn you >>>> >>>> >>>>>are blocking Joe, but he just goes off, gets a new URI from >>>> >>>>yahoo, and >>>> >>>> >>>>>your permission statement is useless. >>>>>Indeed, the entire notion of except clauses is only useful >>>> >>>>if you assume >>>> >>>> >>>>>that there are cases where it is hard to obtain new >>>> >>>>identifiers. There >>>> >>>> >>>>>was some dispute about whether this is a good assumnption >>>> >>>>or not. I, and >>>> >>>> >>>>>some others, do believe that in many enterprises, it is a good >>>>>assumption that obtaining a new enterprise identifier is not easy. >>>> >>>>While agree that outside of walled-gardens your example is not very >>>>useful, I do think this is very useful when your applies-to >>>>is scoped to >>>>a domain. >>>> >>>>This is not limited to enterprise deployments. It may be true >>>>that some >>>>providers give away identities for free, it is not the case >>>>that _all_ >>>>providers do this. In fact, I think the whole argument that >> >>you don't >> >>>>need exceptions becauses identities are free is bogus. >>>> >>>> >>>> >>>>>A second point on exceptions. If an exception represents a >>>> >>>>list, and you >>>> >>>> >>>>>can't dereference that list, then you have to drop the >>>> >>>>entire permission >>>> >>>> >>>>>statement. This is to ensure privacy-safety, so that >>>> >>>>information is not >>>> >>>> >>>>>leaked under any failure condition. >>>>> >>>>>Finally, it needs to be clarified that exceptions still result in >>>>>additive permissions. So, for example, if I have two >>>> >>>>staements like this: >>>> >>>> >>>>> >>>>> example.com >>>>> >>>>> sip:sally@example.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>and >>>>> >>>>> >>>>> example.com >>>>> >>>>> sip:bob@example.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>That if EITHER Sally or Bob subscribes, they will be >>>> >>>>granted permission >>>> >>>> >>>>>to subscribe. Thats because, if Bob subscribes, the first policy >>>>>statement applies to him, resulting in his subscription >>>> >>>>being accepted. >>>> >>>> >>>>>If Sally subscribes, the second applies to her, and her >>>> >>>>subscription is >>>> >>>> >>>>>accepted. >>>>> >>>>>If you try and make except clauses carry across permission >>>> >>>>statements, >>>> >>>> >>>>>you end up in a place where these statements are no longer >>>> >>>>additive, and >>>> >>>> >>>>>you are not privacy safe anymore. >>>>> >>>>>Now, even given these clarifications, the geopriv group is >>>> >>>>not planning >>>> >>>> >>>>>on specifying an except condition at this time. Though they >>>> >>>>consider it >>>> >>>> >>>>>useful, its been ruled out of scope for the initial policy >>>> >>>>document. >>>> >>>> >>>>>Thus, if we wish to align, we would need to also rule it >>>> >>>>out of scope in >>>> >>>> >>>>>the initial version of the specification. >>>>> >>>>>That does not mean it could never be done; indeed, it would be my >>>>>proposal to more or less immediately have a draft defining it, and >>>>>progress this just behind the main specs. >>>>> >>>>>IMHO, it is worth getting alignment to let this feature >>>> >>>>move forward in >>>> >>>> >>>>>a separate specification, behind the main one. >>>>> >>>>>Comments and thoughts? >>>> >>>>I personally do not think we can live without exceptions, >> >>even for a >> >>>>little while. Since the additive approach does not allow me to >>>>explicitly black-list someone and have that override any other >>>>permissions, then the only way I could create a rule that allowed >>>>everyone from example.com except alice would be to list >> >>every single >> >>>>member of example.com explicitly. This is bad enough from a >>>>convenience >>>>perspective--but in reality it is very unlikely example.com >>>>will share >>>>its membership roster with me, so I could not do this even if >>>>I wanted to. >>> >>> >>>The way it works today is that you have a list of >> >>presentities and a list of watchers. The list of watchers is >>what the issues are about. In most systems today, the list of >>watchers is a mirror to the list of presentities, and >>therefore does not include everyone is a domain. >> >>>I think it is ok for now to give permissions to individual >> >>watchers as selected by the presentity. We are not at a stage >>in presence systems where we want to allow everyone at a >>domain to view someone's presence excepting individual x and >>y. But more like 15 to 20 individuals that the presentity >>mostly interacts with in that domain. >> >>>So, instead of allowing, for example, everyone at >> >>example.com except for Bob. I can pick john, alice, ben and >>adam from example.com that I interact with and want to allow >>to be my watchers, and create permissions for them. This >>leaves out bob along with everyone else at example.com. I >>think this is good enough. >> >>So you have allowed John, Alice, Ben and Adam. That is _not_ >>the same as >>"Everyone but Bob". For example, what if Carol joins example.com >>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will >>not include >>her, but the "Everyone but Bob rule" would. > > > Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > That assumes you know about Carol. My point is, these two cases are not the same thing. You might be able to simulate something like exceptions by doing this, if and only if you have full knowledge of the membership of example.com. I suspect that will commonly be false. > /Hisham > > >>Most of the existing systems that mirror the watcher and presentity >>lists are single-domain systems. In an interoperable, multidomain >>system, I think that policy needs will quickly outstrip the >>expressivity >>of the rule language if you don't have exceptions. >> >> >>>Regards, >>>Hisham >>> >>> >>> >>>>I am willing to live with limiting exceptions expressions to >>>>things that >>>>never require external resolution. >>>> >>>> >>>> >>>>>Thanks, >>>>>Jonathan R. >>>> >>>> >>>> >>>>_______________________________________________ >>>>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-admin@ietf.org Tue Nov 25 16:18:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11140; Tue, 25 Nov 2003 16:18:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkaR-0006ce-00; Tue, 25 Nov 2003 16:19:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOkaQ-0006cb-00; Tue, 25 Nov 2003 16:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaM-0001Wl-TF; Tue, 25 Nov 2003 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaD-0001Vx-Nh for simple@optimus.ietf.org; Tue, 25 Nov 2003 16:18:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11128; Tue, 25 Nov 2003 16:18:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkZz-0006cI-00; Tue, 25 Nov 2003 16:18:39 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AOkZy-0006bm-00; Tue, 25 Nov 2003 16:18:38 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 13:17:52 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 13:18:06 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 13:18:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Message-ID: Thread-Topic: FW: I-D ACTION:draft-levin-simple-adhoc-list-01.txt Thread-Index: AcOzmZyvK4uvlGfIQaqcp/ZLgB3Jgw== From: "Orit Levin" To: , X-OriginalArrivalTime: 25 Nov 2003 21:18:11.0118 (UTC) FILETIME=[A1212CE0:01C3B399] Subject: [Simple] FW: I-D ACTION:draft-levin-simple-adhoc-list-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:18:03 -0800 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B399.A0FE4560" ------_=_NextPart_001_01C3B399.A0FE4560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ * To: IETF-Announce: ;=20 * Subject: I-D ACTION:draft-levin-simple-adhoc-list-01.txt=20 * From: Internet-Drafts@ietf.org=20 * Date: Tue, 25 Nov 2003 15:25:13 -0500=20 * Reply-to: Internet-Drafts@ietf.org=20 * Sender: owner-ietf-announce@ietf.org=20 ________________________________ size=3D2 width=3D"100%" align=3Dcenter>=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : Ad-hoc Resource Lists using SUBSCRIBE in = SIMPLE Author(s) : O. Levin Filename : draft-levin-simple-adhoc-list-01.txt Pages : 14 Date : 2003-11-25 =20 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can define an ad-hoc resource list, subscribe to it, and maintain it =FB all within a single SUBSCRIBE dialog. Changes in the state of the resources are reported using the same dialog in any standard SIMPLE format for conveying notifications for lists of resources or individual resources and agreed during the SUBSCRIBE dialog establishment. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt =20 To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. =20 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-levin-simple-adhoc-list-01.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-simple-adhoc-list-01.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. = = = =20 =20 ------_=_NextPart_001_01C3B399.A0FE4560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
size=3D2 = width=3D"100%" align=3Dcenter> 
A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
 
 
=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0 : Ad-hoc Resource Lists using SUBSCRIBE in =
SIMPLE
=A0=A0=A0=A0=A0=A0=A0 =
Author(s)=A0=A0=A0=A0=A0 : O. Levin
=A0=A0=A0=A0=A0=A0=A0 =
Filename=A0=A0=A0=A0=A0=A0 : =
draft-levin-simple-adhoc-list-01.txt
=A0=A0=A0=A0=A0=A0=A0 =
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 14
=A0=A0=A0=A0=A0=A0=A0 =
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : =
2003-11-25
=A0=A0=A0=A0=A0=A0=A0 =

This =
document presents an extension to the Session =
Initiation
Protocol =
(SIP)-Specific Event Notification mechanism for =
subscribing
to a =
homogeneous list of resources.=A0 Instead of the =
subscriber
sending a =
SUBSCRIBE for each resource individually, the =
subscriber
can =
define an ad-hoc resource list, subscribe to it, and maintain =
it
=FB all =
within a single SUBSCRIBE dialog. Changes in the state of =
the
resources =
are reported using the same dialog in any standard =
SIMPLE
format =
for conveying notifications for lists of resources =
or
individual resources and agreed during the =
SUBSCRIBE dialog
establishment.
 
A URL for =
this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-lis=
t-01.txt
 
To remove =
yourself from the IETF Announcement list, send a message to =

ietf-announce-request with the word =
unsubscribe in the body of the message.
 
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
=A0=A0=A0=A0=A0=A0=A0 "get =
draft-levin-simple-adhoc-list-01.txt".
 
A list of =
Internet-Drafts directories can be found =
in
http://www.ietf.org/shadow.html<=
/a> 
or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt
 
 
Internet-Drafts can also be obtained by =
e-mail.
 
Send a =
message to:
=A0=A0=A0=A0=A0=A0=A0 =
mailserv@ietf.org.
In the =
body type:
=A0=A0=A0=A0=A0=A0=A0 "FILE =
/internet-drafts/draft-levin-simple-adhoc-list-01.txt".
=A0=A0=A0=A0=A0=A0=A0 =

NOTE:=A0=A0 The mail server at ietf.org can =
return the document in
=A0=A0=A0=A0=A0=A0=A0 MIME-encoded form by =
using the "mpack" utility.=A0 To use =
this
=A0=A0=A0=A0=A0=A0=A0 feature, insert the =
command "ENCODING mime" before the =
"FILE"
=A0=A0=A0=A0=A0=A0=A0 command.=A0 To decode =
the response(s), you will need "munpack" =
or
=A0=A0=A0=A0=A0=A0=A0 a MIME-compliant mail =
reader.=A0 Different MIME-compliant mail =
readers
=A0=A0=A0=A0=A0=A0=A0 exhibit different =
behavior, especially when dealing with
=A0=A0=A0=A0=A0=A0=A0 "multipart" =
MIME messages (i.e. documents which have been =
split
=A0=A0=A0=A0=A0=A0=A0 up into multiple =
messages), so check your local documentation =
on
=A0=A0=A0=A0=A0=A0=A0 how to manipulate these =
messages.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

Below is =
the data which will enable a MIME compliant mail =
reader
implementation to automatically retrieve the =
ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-levin-simple-adhoc-l= ist-01.txt>

 

= ------_=_NextPart_001_01C3B399.A0FE4560-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 16:19:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11183 for ; Tue, 25 Nov 2003 16:19:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaT-0001Yj-On for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 16:19:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPLJ9Ul005987 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 16:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaT-0001YT-JE for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 16:19:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11140; Tue, 25 Nov 2003 16:18:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkaR-0006ce-00; Tue, 25 Nov 2003 16:19:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOkaQ-0006cb-00; Tue, 25 Nov 2003 16:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaM-0001Wl-TF; Tue, 25 Nov 2003 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaD-0001Vx-Nh for simple@optimus.ietf.org; Tue, 25 Nov 2003 16:18:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11128; Tue, 25 Nov 2003 16:18:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkZz-0006cI-00; Tue, 25 Nov 2003 16:18:39 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AOkZy-0006bm-00; Tue, 25 Nov 2003 16:18:38 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 13:17:52 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 13:18:06 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 13:18:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Message-ID: Thread-Topic: FW: I-D ACTION:draft-levin-simple-adhoc-list-01.txt Thread-Index: AcOzmZyvK4uvlGfIQaqcp/ZLgB3Jgw== From: "Orit Levin" To: , X-OriginalArrivalTime: 25 Nov 2003 21:18:11.0118 (UTC) FILETIME=[A1212CE0:01C3B399] Subject: [Simple] FW: I-D ACTION:draft-levin-simple-adhoc-list-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:18:03 -0800 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B399.A0FE4560" ------_=_NextPart_001_01C3B399.A0FE4560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ * To: IETF-Announce: ;=20 * Subject: I-D ACTION:draft-levin-simple-adhoc-list-01.txt=20 * From: Internet-Drafts@ietf.org=20 * Date: Tue, 25 Nov 2003 15:25:13 -0500=20 * Reply-to: Internet-Drafts@ietf.org=20 * Sender: owner-ietf-announce@ietf.org=20 ________________________________ size=3D2 width=3D"100%" align=3Dcenter>=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : Ad-hoc Resource Lists using SUBSCRIBE in = SIMPLE Author(s) : O. Levin Filename : draft-levin-simple-adhoc-list-01.txt Pages : 14 Date : 2003-11-25 =20 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can define an ad-hoc resource list, subscribe to it, and maintain it =FB all within a single SUBSCRIBE dialog. Changes in the state of the resources are reported using the same dialog in any standard SIMPLE format for conveying notifications for lists of resources or individual resources and agreed during the SUBSCRIBE dialog establishment. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt =20 To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. =20 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-levin-simple-adhoc-list-01.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-simple-adhoc-list-01.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. = = = =20 =20 ------_=_NextPart_001_01C3B399.A0FE4560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
size=3D2 = width=3D"100%" align=3Dcenter> 
A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
 
 
=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0 : Ad-hoc Resource Lists using SUBSCRIBE in =
SIMPLE
=A0=A0=A0=A0=A0=A0=A0 =
Author(s)=A0=A0=A0=A0=A0 : O. Levin
=A0=A0=A0=A0=A0=A0=A0 =
Filename=A0=A0=A0=A0=A0=A0 : =
draft-levin-simple-adhoc-list-01.txt
=A0=A0=A0=A0=A0=A0=A0 =
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 14
=A0=A0=A0=A0=A0=A0=A0 =
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : =
2003-11-25
=A0=A0=A0=A0=A0=A0=A0 =

This =
document presents an extension to the Session =
Initiation
Protocol =
(SIP)-Specific Event Notification mechanism for =
subscribing
to a =
homogeneous list of resources.=A0 Instead of the =
subscriber
sending a =
SUBSCRIBE for each resource individually, the =
subscriber
can =
define an ad-hoc resource list, subscribe to it, and maintain =
it
=FB all =
within a single SUBSCRIBE dialog. Changes in the state of =
the
resources =
are reported using the same dialog in any standard =
SIMPLE
format =
for conveying notifications for lists of resources =
or
individual resources and agreed during the =
SUBSCRIBE dialog
establishment.
 
A URL for =
this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-lis=
t-01.txt
 
To remove =
yourself from the IETF Announcement list, send a message to =

ietf-announce-request with the word =
unsubscribe in the body of the message.
 
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
=A0=A0=A0=A0=A0=A0=A0 "get =
draft-levin-simple-adhoc-list-01.txt".
 
A list of =
Internet-Drafts directories can be found =
in
http://www.ietf.org/shadow.html<=
/a> 
or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt
 
 
Internet-Drafts can also be obtained by =
e-mail.
 
Send a =
message to:
=A0=A0=A0=A0=A0=A0=A0 =
mailserv@ietf.org.
In the =
body type:
=A0=A0=A0=A0=A0=A0=A0 "FILE =
/internet-drafts/draft-levin-simple-adhoc-list-01.txt".
=A0=A0=A0=A0=A0=A0=A0 =

NOTE:=A0=A0 The mail server at ietf.org can =
return the document in
=A0=A0=A0=A0=A0=A0=A0 MIME-encoded form by =
using the "mpack" utility.=A0 To use =
this
=A0=A0=A0=A0=A0=A0=A0 feature, insert the =
command "ENCODING mime" before the =
"FILE"
=A0=A0=A0=A0=A0=A0=A0 command.=A0 To decode =
the response(s), you will need "munpack" =
or
=A0=A0=A0=A0=A0=A0=A0 a MIME-compliant mail =
reader.=A0 Different MIME-compliant mail =
readers
=A0=A0=A0=A0=A0=A0=A0 exhibit different =
behavior, especially when dealing with
=A0=A0=A0=A0=A0=A0=A0 "multipart" =
MIME messages (i.e. documents which have been =
split
=A0=A0=A0=A0=A0=A0=A0 up into multiple =
messages), so check your local documentation =
on
=A0=A0=A0=A0=A0=A0=A0 how to manipulate these =
messages.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

Below is =
the data which will enable a MIME compliant mail =
reader
implementation to automatically retrieve the =
ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-levin-simple-adhoc-l= ist-01.txt>

 

= ------_=_NextPart_001_01C3B399.A0FE4560-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Nov 25 16:35:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11880; Tue, 25 Nov 2003 16:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkpw-00070B-00; Tue, 25 Nov 2003 16:35:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOkpw-000706-00; Tue, 25 Nov 2003 16:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkpp-0002gt-QS; Tue, 25 Nov 2003 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkpD-0002gF-Uw for simple@optimus.ietf.org; Tue, 25 Nov 2003 16:34:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11843 for ; Tue, 25 Nov 2003 16:34:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkpB-0006yx-00 for simple@ietf.org; Tue, 25 Nov 2003 16:34:21 -0500 Received: from [202.144.91.188] (helo=ipgen-india.com) by ietf-mx with esmtp (Exim 4.12) id 1AOkp3-0006yg-00 for simple@ietf.org; Tue, 25 Nov 2003 16:34:15 -0500 Received: from pop3.sify.net [202.144.76.11] by ipgen-india.com [] with DomainPOP (MDaemon.PRO.v5.0.7.R) for ; Wed, 26 Nov 2003 03:10:42 +0530 Delivered-To: ipgen-india.com-prem@ipgen-india.com X-Filter: xFilter/SifyMail - No Filter defined (http://mail.sify.com) Received: (sifymail 17078 invoked by uid 7010); Wed Nov 26 02:40:01 2003 Received: (sifymail 17076 invoked by uid 7010); 26 Nov 2003 02:40:01 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.11 with SMTP; 26 Nov 2003 02:40:01 +0530 Received: (sifymail 24538 invoked by uid 7005); 26 Nov 2003 02:40:01 +0530 Received: from 202.144.76.19 (HELO WMRP01.maa.sify.net) (202.144.76.19) by 202.144.76.19 with SMTP; 26 Nov 2003 02:40:01 +0530 Received: (sifymail 24452 invoked by uid 7005); 26 Nov 2003 02:39:08 +0530 Received: from 132.151.6.22 (HELO optimus.ietf.org) (132.151.6.22) by 202.144.76.19 with SMTP; 26 Nov 2003 02:39:08 +0530 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaM-0001WR-6k; Tue, 25 Nov 2003 16:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkaD-0001Vx-Li for sipping@optimus.ietf.org; Tue, 25 Nov 2003 16:18:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11128; Tue, 25 Nov 2003 16:18:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkZz-0006cI-00; Tue, 25 Nov 2003 16:18:39 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx with esmtp (Exim 4.12) id 1AOkZy-0006bm-00; Tue, 25 Nov 2003 16:18:38 -0500 Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 13:17:52 -0800 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Nov 2003 13:18:06 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 25 Nov 2003 13:18:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Message-ID: Thread-Topic: FW: I-D ACTION:draft-levin-simple-adhoc-list-01.txt Thread-Index: AcOzmZyvK4uvlGfIQaqcp/ZLgB3Jgw== From: "Orit Levin" To: , X-OriginalArrivalTime: 25 Nov 2003 21:18:11.0118 (UTC) FILETIME=[A1212CE0:01C3B399] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.19 1.33 0/0/N X-Spam-Rating: 202.144.76.11 1.33 0/0/N X-MDRemoteIP: 202.144.76.11 X-MDRcpt-To: simple@ietf.org X-MDaemon-Deliver-To: simple@ietf.org Subject: [Simple] [Sipping] FW: I-D ACTION:draft-levin-simple-adhoc-list-01.txt Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 13:18:03 -0800 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B399.A0FE4560" ------_=_NextPart_001_01C3B399.A0FE4560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ________________________________ * To: IETF-Announce: ;=20 * Subject: I-D ACTION:draft-levin-simple-adhoc-list-01.txt=20 * From: Internet-Drafts@ietf.org=20 * Date: Tue, 25 Nov 2003 15:25:13 -0500=20 * Reply-to: Internet-Drafts@ietf.org=20 * Sender: owner-ietf-announce@ietf.org=20 ________________________________ size=3D2 width=3D"100%" align=3Dcenter>=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : Ad-hoc Resource Lists using SUBSCRIBE in = SIMPLE Author(s) : O. Levin Filename : draft-levin-simple-adhoc-list-01.txt Pages : 14 Date : 2003-11-25 =20 This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of the subscriber sending a SUBSCRIBE for each resource individually, the subscriber can define an ad-hoc resource list, subscribe to it, and maintain it =FB all within a single SUBSCRIBE dialog. Changes in the state of the resources are reported using the same dialog in any standard SIMPLE format for conveying notifications for lists of resources or individual resources and agreed during the SUBSCRIBE dialog establishment. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-list-01.txt =20 To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. =20 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-levin-simple-adhoc-list-01.txt". =20 A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 =20 Internet-Drafts can also be obtained by e-mail. =20 Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-simple-adhoc-list-01.txt". =20 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. =20 =20 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. = = = =20 =20 ------_=_NextPart_001_01C3B399.A0FE4560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
size=3D2 = width=3D"100%" align=3Dcenter> 
A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
 
 
=A0=A0=A0=A0=A0=A0=A0 Title=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0 : Ad-hoc Resource Lists using SUBSCRIBE in =
SIMPLE
=A0=A0=A0=A0=A0=A0=A0 =
Author(s)=A0=A0=A0=A0=A0 : O. Levin
=A0=A0=A0=A0=A0=A0=A0 =
Filename=A0=A0=A0=A0=A0=A0 : =
draft-levin-simple-adhoc-list-01.txt
=A0=A0=A0=A0=A0=A0=A0 =
Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 14
=A0=A0=A0=A0=A0=A0=A0 =
Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : =
2003-11-25
=A0=A0=A0=A0=A0=A0=A0 =

This =
document presents an extension to the Session =
Initiation
Protocol =
(SIP)-Specific Event Notification mechanism for =
subscribing
to a =
homogeneous list of resources.=A0 Instead of the =
subscriber
sending a =
SUBSCRIBE for each resource individually, the =
subscriber
can =
define an ad-hoc resource list, subscribe to it, and maintain =
it
=FB all =
within a single SUBSCRIBE dialog. Changes in the state of =
the
resources =
are reported using the same dialog in any standard =
SIMPLE
format =
for conveying notifications for lists of resources =
or
individual resources and agreed during the =
SUBSCRIBE dialog
establishment.
 
A URL for =
this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levin-simple-adhoc-lis=
t-01.txt
 
To remove =
yourself from the IETF Announcement list, send a message to =

ietf-announce-request with the word =
unsubscribe in the body of the message.
 
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
=A0=A0=A0=A0=A0=A0=A0 "get =
draft-levin-simple-adhoc-list-01.txt".
 
A list of =
Internet-Drafts directories can be found =
in
http://www.ietf.org/shadow.html<=
/a> 
or ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt
 
 
Internet-Drafts can also be obtained by =
e-mail.
 
Send a =
message to:
=A0=A0=A0=A0=A0=A0=A0 =
mailserv@ietf.org.
In the =
body type:
=A0=A0=A0=A0=A0=A0=A0 "FILE =
/internet-drafts/draft-levin-simple-adhoc-list-01.txt".
=A0=A0=A0=A0=A0=A0=A0 =

NOTE:=A0=A0 The mail server at ietf.org can =
return the document in
=A0=A0=A0=A0=A0=A0=A0 MIME-encoded form by =
using the "mpack" utility.=A0 To use =
this
=A0=A0=A0=A0=A0=A0=A0 feature, insert the =
command "ENCODING mime" before the =
"FILE"
=A0=A0=A0=A0=A0=A0=A0 command.=A0 To decode =
the response(s), you will need "munpack" =
or
=A0=A0=A0=A0=A0=A0=A0 a MIME-compliant mail =
reader.=A0 Different MIME-compliant mail =
readers
=A0=A0=A0=A0=A0=A0=A0 exhibit different =
behavior, especially when dealing with
=A0=A0=A0=A0=A0=A0=A0 "multipart" =
MIME messages (i.e. documents which have been =
split
=A0=A0=A0=A0=A0=A0=A0 up into multiple =
messages), so check your local documentation =
on
=A0=A0=A0=A0=A0=A0=A0 how to manipulate these =
messages.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

Below is =
the data which will enable a MIME compliant mail =
reader
implementation to automatically retrieve the =
ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-levin-simple-adhoc-l= ist-01.txt>

 

= ------_=_NextPart_001_01C3B399.A0FE4560-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ 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-admin@ietf.org Tue Nov 25 18:14:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17193; Tue, 25 Nov 2003 18:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOmOe-0001mA-00; Tue, 25 Nov 2003 18:15:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOmOe-0001m6-00; Tue, 25 Nov 2003 18:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmOc-0001Yy-TF; Tue, 25 Nov 2003 18:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmO3-0001YG-82 for simple@optimus.ietf.org; Tue, 25 Nov 2003 18:14:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17126 for ; Tue, 25 Nov 2003 18:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOmO0-0001lm-00 for simple@ietf.org; Tue, 25 Nov 2003 18:14:24 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOmNz-0001lN-00 for simple@ietf.org; Tue, 25 Nov 2003 18:14:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAPNDrd18951 for ; Tue, 25 Nov 2003 17:13:53 -0600 Subject: Re: [Simple] Draft minutes from the SIMPLE IETF58 meeting From: Robert Sparks To: simple@ietf.org In-Reply-To: <1069304667.973.75.camel@RjS.localdomain> References: <1069304667.973.75.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1069802033.1007.3.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:13:53 -0600 Content-Transfer-Encoding: 7bit I've received only one comment on the draft minutes so far (a minor editorial tweak). If you haven't looked these over yet, please do so now. RjS On Wed, 2003-11-19 at 23:04, Robert Sparks wrote: > Draft minutes for last week's meeting are available at > http://www.nostrum.com/~rjsparks/minutes-simple-ietf58.txt > > Please provide corrections or comments to the list or directly > to me no later than Wednesday November 26. > > Thanks, > > RjS > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Nov 25 18:15:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17261 for ; Tue, 25 Nov 2003 18:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmOi-0001Zy-D6 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 18:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPNF87m006064 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 18:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmOi-0001Zi-6U for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 18:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17193; Tue, 25 Nov 2003 18:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOmOe-0001mA-00; Tue, 25 Nov 2003 18:15:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOmOe-0001m6-00; Tue, 25 Nov 2003 18:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmOc-0001Yy-TF; Tue, 25 Nov 2003 18:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOmO3-0001YG-82 for simple@optimus.ietf.org; Tue, 25 Nov 2003 18:14:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17126 for ; Tue, 25 Nov 2003 18:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOmO0-0001lm-00 for simple@ietf.org; Tue, 25 Nov 2003 18:14:24 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOmNz-0001lN-00 for simple@ietf.org; Tue, 25 Nov 2003 18:14:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAPNDrd18951 for ; Tue, 25 Nov 2003 17:13:53 -0600 Subject: Re: [Simple] Draft minutes from the SIMPLE IETF58 meeting From: Robert Sparks To: simple@ietf.org In-Reply-To: <1069304667.973.75.camel@RjS.localdomain> References: <1069304667.973.75.camel@RjS.localdomain> Content-Type: text/plain Message-Id: <1069802033.1007.3.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 17:13:53 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've received only one comment on the draft minutes so far (a minor editorial tweak). If you haven't looked these over yet, please do so now. RjS On Wed, 2003-11-19 at 23:04, Robert Sparks wrote: > Draft minutes for last week's meeting are available at > http://www.nostrum.com/~rjsparks/minutes-simple-ietf58.txt > > Please provide corrections or comments to the list or directly > to me no later than Wednesday November 26. > > Thanks, > > RjS > > > _______________________________________________ > 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-admin@ietf.org Tue Nov 25 23:55:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25056; Tue, 25 Nov 2003 23:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOrij-0006Uw-00; Tue, 25 Nov 2003 23:56:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOrij-0006Uq-00; Tue, 25 Nov 2003 23:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOric-0007XT-Gc; Tue, 25 Nov 2003 23:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOa3Y-0007g6-LV for simple@optimus.ietf.org; Tue, 25 Nov 2003 05:04:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10655 for ; Tue, 25 Nov 2003 05:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOa3V-0001C9-00 for simple@ietf.org; Tue, 25 Nov 2003 05:04:25 -0500 Received: from web80709.mail.yahoo.com ([66.163.170.66]) by ietf-mx with smtp (Exim 4.12) id 1AOa3V-0001C4-00 for simple@ietf.org; Tue, 25 Nov 2003 05:04:25 -0500 Message-ID: <20031125100424.6022.qmail@web80709.mail.yahoo.com> Received: from [195.167.202.148] by web80709.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 02:04:24 PST From: "Ar c'hasour" To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Comment on draft-ietf-simple-xcap-package-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 02:04:24 -0800 (PST) Hi, Why is it not possible to send the XML document itself (and not only its version) in the first NOTIFY request sent in response to an initial SUBSCRIBE? Is there a workaround to retrieve the XML document via SIP? Thanks, Patrig __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Nov 25 23:56:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25076 for ; Tue, 25 Nov 2003 23:56:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrim-0007Yg-RF for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 23:56:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ4uCu7029050 for simple-archive@odin.ietf.org; Tue, 25 Nov 2003 23:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrim-0007YT-NV for simple-web-archive@optimus.ietf.org; Tue, 25 Nov 2003 23:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25056; Tue, 25 Nov 2003 23:55:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOrij-0006Uw-00; Tue, 25 Nov 2003 23:56:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOrij-0006Uq-00; Tue, 25 Nov 2003 23:56:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOric-0007XT-Gc; Tue, 25 Nov 2003 23:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOa3Y-0007g6-LV for simple@optimus.ietf.org; Tue, 25 Nov 2003 05:04:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10655 for ; Tue, 25 Nov 2003 05:04:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOa3V-0001C9-00 for simple@ietf.org; Tue, 25 Nov 2003 05:04:25 -0500 Received: from web80709.mail.yahoo.com ([66.163.170.66]) by ietf-mx with smtp (Exim 4.12) id 1AOa3V-0001C4-00 for simple@ietf.org; Tue, 25 Nov 2003 05:04:25 -0500 Message-ID: <20031125100424.6022.qmail@web80709.mail.yahoo.com> Received: from [195.167.202.148] by web80709.mail.yahoo.com via HTTP; Tue, 25 Nov 2003 02:04:24 PST From: "Ar c'hasour" To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] Comment on draft-ietf-simple-xcap-package-00 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 25 Nov 2003 02:04:24 -0800 (PST) Hi, Why is it not possible to send the XML document itself (and not only its version) in the first NOTIFY request sent in response to an initial SUBSCRIBE? Is there a workaround to retrieve the XML document via SIP? Thanks, Patrig __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 26 01:36:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27523; Wed, 26 Nov 2003 01:36:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOtIO-0007j7-00; Wed, 26 Nov 2003 01:37:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOtIN-0007j3-00; Wed, 26 Nov 2003 01:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtIL-0003mz-11; Wed, 26 Nov 2003 01:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtHw-0003mU-UG for simple@optimus.ietf.org; Wed, 26 Nov 2003 01:36:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27513 for ; Wed, 26 Nov 2003 01:36:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOtHt-0007iu-00 for simple@ietf.org; Wed, 26 Nov 2003 01:36:33 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOtHt-0007ih-00 for simple@ietf.org; Wed, 26 Nov 2003 01:36:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAQ6Ztd25130; Wed, 26 Nov 2003 00:35:55 -0600 Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions From: Robert Sparks To: Ben Campbell Cc: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: <3FC3C480.5080908@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> Content-Type: text/plain Message-Id: <1069828552.1007.56.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 00:35:52 -0600 Content-Transfer-Encoding: 7bit (speaking from the floor) In the presence/IM systems I've been using on a daily basis for some time now, I do not have a way to say "Allow everybody in foo.com except bar" and I still find these systems useful. On reflection, when using future systems I think I will prefer the model of explicitly listing those people I wish to authorize over excepting individuals from a set I cannot control and possibly cannot know. Thus, I don't think it is absolutely necessary to have that kind of statement in the initial xcap-auth mechanism. I do see the power of having such a statement to some applications that may consume presence, and I would very much like to have such a statement available. I think it is acceptable for this functionality to be an extension of the base xcap-auth tool. RjS On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > >>So you have allowed John, Alice, Ben and Adam. That is _not_ > >>the same as > >>"Everyone but Bob". For example, what if Carol joins example.com > >>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will > >>not include > >>her, but the "Everyone but Bob rule" would. > > > > > > Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > > > > That assumes you know about Carol. My point is, these two cases are not > the same thing. You might be able to simulate something like exceptions > by doing this, if and only if you have full knowledge of the membership > of example.com. I suspect that will commonly be false. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 26 01:37:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27554 for ; Wed, 26 Nov 2003 01:37:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtIU-0003oo-90 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 01:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ6b9An014672 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 01:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtIS-0003oZ-28 for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 01:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27523; Wed, 26 Nov 2003 01:36:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOtIO-0007j7-00; Wed, 26 Nov 2003 01:37:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOtIN-0007j3-00; Wed, 26 Nov 2003 01:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtIL-0003mz-11; Wed, 26 Nov 2003 01:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtHw-0003mU-UG for simple@optimus.ietf.org; Wed, 26 Nov 2003 01:36:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27513 for ; Wed, 26 Nov 2003 01:36:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOtHt-0007iu-00 for simple@ietf.org; Wed, 26 Nov 2003 01:36:33 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOtHt-0007ih-00 for simple@ietf.org; Wed, 26 Nov 2003 01:36:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAQ6Ztd25130; Wed, 26 Nov 2003 00:35:55 -0600 Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions From: Robert Sparks To: Ben Campbell Cc: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: <3FC3C480.5080908@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> Content-Type: text/plain Message-Id: <1069828552.1007.56.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 00:35:52 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (speaking from the floor) In the presence/IM systems I've been using on a daily basis for some time now, I do not have a way to say "Allow everybody in foo.com except bar" and I still find these systems useful. On reflection, when using future systems I think I will prefer the model of explicitly listing those people I wish to authorize over excepting individuals from a set I cannot control and possibly cannot know. Thus, I don't think it is absolutely necessary to have that kind of statement in the initial xcap-auth mechanism. I do see the power of having such a statement to some applications that may consume presence, and I would very much like to have such a statement available. I think it is acceptable for this functionality to be an extension of the base xcap-auth tool. RjS On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > >>So you have allowed John, Alice, Ben and Adam. That is _not_ > >>the same as > >>"Everyone but Bob". For example, what if Carol joins example.com > >>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will > >>not include > >>her, but the "Everyone but Bob rule" would. > > > > > > Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > > > > That assumes you know about Carol. My point is, these two cases are not > the same thing. You might be able to simulate something like exceptions > by doing this, if and only if you have full knowledge of the membership > of example.com. I suspect that will commonly be false. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 26 05:56:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01918; Wed, 26 Nov 2003 05:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOxLy-0003XQ-00; Wed, 26 Nov 2003 05:57:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOxLx-0003XN-00; Wed, 26 Nov 2003 05:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxLw-0002Ui-EW; Wed, 26 Nov 2003 05:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxL9-0002U7-VT for simple@optimus.ietf.org; Wed, 26 Nov 2003 05:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01896; Wed, 26 Nov 2003 05:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOxL6-0003Wb-00; Wed, 26 Nov 2003 05:56:08 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AOxL5-0003WY-00; Wed, 26 Nov 2003 05:56:07 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hAQAu7J07880; Wed, 26 Nov 2003 11:56:07 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAQAu7m10537; Wed, 26 Nov 2003 11:56:07 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 11:55:49 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0489@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Jonathan Rosenberg , Simple WG , "'geopriv@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Supported Permissions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 11:54:45 +0100 Hi Jonathan, Hi all, in section 5 of the xcap-authz draft so-called "supported permissions" are described. if i understood them correctly then their purpose is to allow the entity which creates the rules to dynamically determine the current version of the xcap-authz policies (i.e., which xml attributes are understood by the server). it is certainly important to think about extensibility of the authorization policies. in geopriv we have also thought a little about these issues. have you thought about other mechanisms for determining the version? maybe there are simpler mechanisms. looking at the example in section 5.6 i had the impression that you also combine the authorization policies with the actual data. i think that some information is missing in the xml schema (and in the example) to be complete. in any case i think that they should be separated. please correct me if i misunderstood your intention. Ciao Hannes _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 26 05:57:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01970 for ; Wed, 26 Nov 2003 05:57:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxM3-0002XQ-JV for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 05:57:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQAv7lX009725 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 05:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxM2-0002Wh-Ja for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 05:57:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01918; Wed, 26 Nov 2003 05:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOxLy-0003XQ-00; Wed, 26 Nov 2003 05:57:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AOxLx-0003XN-00; Wed, 26 Nov 2003 05:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxLw-0002Ui-EW; Wed, 26 Nov 2003 05:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOxL9-0002U7-VT for simple@optimus.ietf.org; Wed, 26 Nov 2003 05:56:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01896; Wed, 26 Nov 2003 05:55:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOxL6-0003Wb-00; Wed, 26 Nov 2003 05:56:08 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1AOxL5-0003WY-00; Wed, 26 Nov 2003 05:56:07 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hAQAu7J07880; Wed, 26 Nov 2003 11:56:07 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hAQAu7m10537; Wed, 26 Nov 2003 11:56:07 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 11:55:49 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0489@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Jonathan Rosenberg , Simple WG , "'geopriv@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Supported Permissions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 11:54:45 +0100 Hi Jonathan, Hi all, in section 5 of the xcap-authz draft so-called "supported permissions" are described. if i understood them correctly then their purpose is to allow the entity which creates the rules to dynamically determine the current version of the xcap-authz policies (i.e., which xml attributes are understood by the server). it is certainly important to think about extensibility of the authorization policies. in geopriv we have also thought a little about these issues. have you thought about other mechanisms for determining the version? maybe there are simpler mechanisms. looking at the example in section 5.6 i had the impression that you also combine the authorization policies with the actual data. i think that some information is missing in the xml schema (and in the example) to be complete. in any case i think that they should be separated. please correct me if i misunderstood your intention. Ciao Hannes _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 26 09:32:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08054; Wed, 26 Nov 2003 09:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0j2-0006Ia-00; Wed, 26 Nov 2003 09:33:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0j2-0006IX-00; Wed, 26 Nov 2003 09:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0iz-0005Tv-84; Wed, 26 Nov 2003 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0ik-0005TR-Pu for simple@optimus.ietf.org; Wed, 26 Nov 2003 09:32:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08039 for ; Wed, 26 Nov 2003 09:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0ij-0006IF-00 for simple@ietf.org; Wed, 26 Nov 2003 09:32:45 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AP0ii-0006Hw-00 for simple@ietf.org; Wed, 26 Nov 2003 09:32:44 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAQEVrnG028960; Wed, 26 Nov 2003 08:32:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC4B951.2090508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> In-Reply-To: <1069828552.1007.56.camel@RjS.localdomain> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 08:31:45 -0600 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > (speaking from the floor) > > In the presence/IM systems I've been using on a daily basis for > some time now, I do not have a way to say "Allow everybody in > foo.com except bar" and I still find these systems useful. I do have to point out that most of the existing, big commercially deployed systems, are single-domain, non-interoperable systems. We make due with them because that is what exists. I did not think that is what we are trying to build here. Let me back off from saying you cannot build a useful system without exceptions. Let me instead state that I have endured a number of customer requests for authorization models that cannot be implemented without exceptions. > > On reflection, when using future systems I think I will prefer the model > of explicitly listing those people I wish to authorize over excepting > individuals from a set I cannot control and possibly cannot know. > > Thus, I don't think it is absolutely necessary to have that kind of > statement in the initial xcap-auth mechanism. > Out of curiosity, do you see it necessary to be able to say a rule applies to a domain at all? Or to generalize, to any "group" where membership is determined when the rule is applied, rather than when it is created? > I do see the power of having such a statement to some applications > that may consume presence, and I would very much like to have such > a statement available. I think it is acceptable for this functionality > to be an extension of the base xcap-auth tool. > > RjS > > On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > >>>>So you have allowed John, Alice, Ben and Adam. That is _not_ >>>>the same as >>>>"Everyone but Bob". For example, what if Carol joins example.com >>>>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will >>>>not include >>>>her, but the "Everyone but Bob rule" would. >>> >>> >>>Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. >>> >> >>That assumes you know about Carol. My point is, these two cases are not >>the same thing. You might be able to simulate something like exceptions >>by doing this, if and only if you have full knowledge of the membership >>of example.com. I suspect that will commonly be false. >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 26 09:33:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08074 for ; Wed, 26 Nov 2003 09:33:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0j5-0005Up-7d for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 09:33:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEX7kt021127 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 09:33:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0j5-0005Ug-2o for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 09:33:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08054; Wed, 26 Nov 2003 09:32:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0j2-0006Ia-00; Wed, 26 Nov 2003 09:33:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0j2-0006IX-00; Wed, 26 Nov 2003 09:33:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0iz-0005Tv-84; Wed, 26 Nov 2003 09:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0ik-0005TR-Pu for simple@optimus.ietf.org; Wed, 26 Nov 2003 09:32:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08039 for ; Wed, 26 Nov 2003 09:32:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0ij-0006IF-00 for simple@ietf.org; Wed, 26 Nov 2003 09:32:45 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AP0ii-0006Hw-00 for simple@ietf.org; Wed, 26 Nov 2003 09:32:44 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAQEVrnG028960; Wed, 26 Nov 2003 08:32:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC4B951.2090508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> In-Reply-To: <1069828552.1007.56.camel@RjS.localdomain> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 08:31:45 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > (speaking from the floor) > > In the presence/IM systems I've been using on a daily basis for > some time now, I do not have a way to say "Allow everybody in > foo.com except bar" and I still find these systems useful. I do have to point out that most of the existing, big commercially deployed systems, are single-domain, non-interoperable systems. We make due with them because that is what exists. I did not think that is what we are trying to build here. Let me back off from saying you cannot build a useful system without exceptions. Let me instead state that I have endured a number of customer requests for authorization models that cannot be implemented without exceptions. > > On reflection, when using future systems I think I will prefer the model > of explicitly listing those people I wish to authorize over excepting > individuals from a set I cannot control and possibly cannot know. > > Thus, I don't think it is absolutely necessary to have that kind of > statement in the initial xcap-auth mechanism. > Out of curiosity, do you see it necessary to be able to say a rule applies to a domain at all? Or to generalize, to any "group" where membership is determined when the rule is applied, rather than when it is created? > I do see the power of having such a statement to some applications > that may consume presence, and I would very much like to have such > a statement available. I think it is acceptable for this functionality > to be an extension of the base xcap-auth tool. > > RjS > > On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > >>>>So you have allowed John, Alice, Ben and Adam. That is _not_ >>>>the same as >>>>"Everyone but Bob". For example, what if Carol joins example.com >>>>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will >>>>not include >>>>her, but the "Everyone but Bob rule" would. >>> >>> >>>Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. >>> >> >>That assumes you know about Carol. My point is, these two cases are not >>the same thing. You might be able to simulate something like exceptions >>by doing this, if and only if you have full knowledge of the membership >>of example.com. I suspect that will commonly be false. >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 26 09:39:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08287; Wed, 26 Nov 2003 09:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0pq-0006MT-00; Wed, 26 Nov 2003 09:40:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0pp-0006MQ-00; Wed, 26 Nov 2003 09:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0pm-0006JX-2Z; Wed, 26 Nov 2003 09:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0p9-0006Gt-Vu for simple@optimus.ietf.org; Wed, 26 Nov 2003 09:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08265 for ; Wed, 26 Nov 2003 09:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0p8-0006Lj-00 for simple@ietf.org; Wed, 26 Nov 2003 09:39:22 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AP0p7-0006L6-00 for simple@ietf.org; Wed, 26 Nov 2003 09:39:21 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAQEcl026547 for ; Wed, 26 Nov 2003 08:38:48 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XMNDN>; Wed, 26 Nov 2003 14:38:46 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF2E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jonathan Rosenberg'" , "Drage, Keith (Keith)" Cc: Adam Roach , simple@ietf.org Subject: RE: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 14:38:44 -0000 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 25 November 2003 19:19 > To: Drage, Keith (Keith) > Cc: Adam Roach; simple@ietf.org > Subject: Re: [Simple] Question on draft-ietf-simple-presence-10 and > Allow- Events > > > > Is it > > not the case that presence servers supporting the "presence" event, > > probably (i.e. SHOULD strength) also support the "presence.winfo" > > event template. > > We have never made that a requirement anywhere. I'm not sure its > IETF's job to do that. I understood the following text from section 4.6 of draft-ietf-simple-winfo-package-05 specified this requirement. Have I misread this. "It is RECOMMENDED that user A be allowed to subscribe to their own watcher information for any package. This is true recursively, so that it is RECOMMENDED that a user be able to subscribe to the watcher information for their watcher information for any package." > > > Would it be useful to indicate this support, given > > that the support of one package is only a SHOULD, given the support > > of the other, or do you have some other way of determining this > > information? Thus user A subscribing for the presence of user B > > would get an indication of whether user A could see other users, > > e.g. user B, watching him. > > I agree that learning other packages that are supported would > be useful. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 26 09:40:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08321 for ; Wed, 26 Nov 2003 09:40:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0pt-0006LX-E7 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 09:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEe91l024381 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 09:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0ps-0006L7-I9 for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 09:40:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08287; Wed, 26 Nov 2003 09:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0pq-0006MT-00; Wed, 26 Nov 2003 09:40:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0pp-0006MQ-00; Wed, 26 Nov 2003 09:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0pm-0006JX-2Z; Wed, 26 Nov 2003 09:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0p9-0006Gt-Vu for simple@optimus.ietf.org; Wed, 26 Nov 2003 09:39:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08265 for ; Wed, 26 Nov 2003 09:39:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0p8-0006Lj-00 for simple@ietf.org; Wed, 26 Nov 2003 09:39:22 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AP0p7-0006L6-00 for simple@ietf.org; Wed, 26 Nov 2003 09:39:21 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAQEcl026547 for ; Wed, 26 Nov 2003 08:38:48 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59) id <4M3XMNDN>; Wed, 26 Nov 2003 14:38:46 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF2E@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jonathan Rosenberg'" , "Drage, Keith (Keith)" Cc: Adam Roach , simple@ietf.org Subject: RE: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 14:38:44 -0000 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 25 November 2003 19:19 > To: Drage, Keith (Keith) > Cc: Adam Roach; simple@ietf.org > Subject: Re: [Simple] Question on draft-ietf-simple-presence-10 and > Allow- Events > > > > Is it > > not the case that presence servers supporting the "presence" event, > > probably (i.e. SHOULD strength) also support the "presence.winfo" > > event template. > > We have never made that a requirement anywhere. I'm not sure its > IETF's job to do that. I understood the following text from section 4.6 of draft-ietf-simple-winfo-package-05 specified this requirement. Have I misread this. "It is RECOMMENDED that user A be allowed to subscribe to their own watcher information for any package. This is true recursively, so that it is RECOMMENDED that a user be able to subscribe to the watcher information for their watcher information for any package." > > > Would it be useful to indicate this support, given > > that the support of one package is only a SHOULD, given the support > > of the other, or do you have some other way of determining this > > information? Thus user A subscribing for the presence of user B > > would get an indication of whether user A could see other users, > > e.g. user B, watching him. > > I agree that learning other packages that are supported would > be useful. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 26 09:41:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08381; Wed, 26 Nov 2003 09:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rh-0006Nf-00; Wed, 26 Nov 2003 09:42:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0rh-0006Nc-00; Wed, 26 Nov 2003 09:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rh-0006R2-1Z; Wed, 26 Nov 2003 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rW-0006Ob-29 for simple@optimus.ietf.org; Wed, 26 Nov 2003 09:41:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08374 for ; Wed, 26 Nov 2003 09:41:35 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rU-0006NW-00 for simple@ietf.org; Wed, 26 Nov 2003 09:41:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rR-0006NS-00 for simple@ietf.org; Wed, 26 Nov 2003 09:41:45 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQEfiM13841 for ; Wed, 26 Nov 2003 16:41:44 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 16:41:42 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 06:41:04 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOz59tsgmJ7fkilRY2ojcDA3gusCQAQzOSg To: , Cc: , , X-OriginalArrivalTime: 26 Nov 2003 14:41:04.0518 (UTC) FILETIME=[51C84A60:01C3B42B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:41:02 -0500 Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >ext Robert Sparks >Sent: Wednesday, November 26, 2003 1:36 AM >To: Ben Campbell >Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >simple@ietf.org >Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions > > >(speaking from the floor) > >In the presence/IM systems I've been using on a daily basis for >some time now, I do not have a way to say "Allow everybody in >foo.com except bar" and I still find these systems useful. > Shall we conclude from this that current restrictions of systems is a = useful measure to build future systems? I do believe that exceptions would be useful, in particular in = inter-domain and interoperable systems. Since I believe that's what is = tried to be built, exceptions should be considered.=20 Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 26 09:42:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08423 for ; Wed, 26 Nov 2003 09:42:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rk-0006Vh-6i for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 09:42:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQEg4HS025019 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 09:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rk-0006VS-2q for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 09:42:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08381; Wed, 26 Nov 2003 09:41:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rh-0006Nf-00; Wed, 26 Nov 2003 09:42:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP0rh-0006Nc-00; Wed, 26 Nov 2003 09:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rh-0006R2-1Z; Wed, 26 Nov 2003 09:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP0rW-0006Ob-29 for simple@optimus.ietf.org; Wed, 26 Nov 2003 09:41:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08374 for ; Wed, 26 Nov 2003 09:41:35 -0500 (EST) From: Dirk.Trossen@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rU-0006NW-00 for simple@ietf.org; Wed, 26 Nov 2003 09:41:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AP0rR-0006NS-00 for simple@ietf.org; Wed, 26 Nov 2003 09:41:45 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQEfiM13841 for ; Wed, 26 Nov 2003 16:41:44 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 16:41:42 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 06:41:04 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcOz59tsgmJ7fkilRY2ojcDA3gusCQAQzOSg To: , Cc: , , X-OriginalArrivalTime: 26 Nov 2003 14:41:04.0518 (UTC) FILETIME=[51C84A60:01C3B42B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:41:02 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original Message----- >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >ext Robert Sparks >Sent: Wednesday, November 26, 2003 1:36 AM >To: Ben Campbell >Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >simple@ietf.org >Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions > > >(speaking from the floor) > >In the presence/IM systems I've been using on a daily basis for >some time now, I do not have a way to say "Allow everybody in >foo.com except bar" and I still find these systems useful. > Shall we conclude from this that current restrictions of systems is a = useful measure to build future systems? I do believe that exceptions would be useful, in particular in = inter-domain and interoperable systems. Since I believe that's what is = tried to be built, exceptions should be considered.=20 Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Nov 26 10:16:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11212; Wed, 26 Nov 2003 10:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Pa-0006zX-00; Wed, 26 Nov 2003 10:17:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP1PZ-0006zU-00; Wed, 26 Nov 2003 10:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1PZ-0001G4-RS; Wed, 26 Nov 2003 10:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1PO-0001Fe-LV for simple@optimus.ietf.org; Wed, 26 Nov 2003 10:16:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11188 for ; Wed, 26 Nov 2003 10:16:35 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1PM-0006zI-00 for simple@ietf.org; Wed, 26 Nov 2003 10:16:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AP1PL-0006zF-00 for simple@ietf.org; Wed, 26 Nov 2003 10:16:47 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQFGiQ13444 for ; Wed, 26 Nov 2003 17:16:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 17:16:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 17:16:43 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 17:16:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 2: validity Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CB@esebe013.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 2: validity Thread-Index: AcOyzl/FxmmSFDZfQxCG/QvZdZzIlQBXnRiw To: , Cc: X-OriginalArrivalTime: 26 Nov 2003 15:16:43.0171 (UTC) FILETIME=[4C84D730:01C3B430] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 17:16:42 +0200 Content-Transfer-Encoding: quoted-printable > > As such, I would propose to adopt the validity condition=20 > element. I=20 > > think its valuable, independent of any desire to align=20 > with geopriv. > >=20 > > Comments? >=20 > I agree. I also agree. Also, this would seem to fulfill one of the things = discussed in the on-demand authorization draft in SIPPING. Cheers, Aki =20 > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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 exim@www1.ietf.org Wed Nov 26 10:17:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11301 for ; Wed, 26 Nov 2003 10:17:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1Pd-0001JA-Bi for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 10:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQFH5wC005022 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 10:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1Pd-0001Iv-7e for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 10:17:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11212; Wed, 26 Nov 2003 10:16:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1Pa-0006zX-00; Wed, 26 Nov 2003 10:17:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP1PZ-0006zU-00; Wed, 26 Nov 2003 10:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1PZ-0001G4-RS; Wed, 26 Nov 2003 10:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1PO-0001Fe-LV for simple@optimus.ietf.org; Wed, 26 Nov 2003 10:16:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11188 for ; Wed, 26 Nov 2003 10:16:35 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1PM-0006zI-00 for simple@ietf.org; Wed, 26 Nov 2003 10:16:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AP1PL-0006zF-00 for simple@ietf.org; Wed, 26 Nov 2003 10:16:47 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQFGiQ13444 for ; Wed, 26 Nov 2003 17:16:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 17:16:44 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 17:16:43 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 17:16:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 2: validity Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CB@esebe013.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 2: validity Thread-Index: AcOyzl/FxmmSFDZfQxCG/QvZdZzIlQBXnRiw To: , Cc: X-OriginalArrivalTime: 26 Nov 2003 15:16:43.0171 (UTC) FILETIME=[4C84D730:01C3B430] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 17:16:42 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > As such, I would propose to adopt the validity condition=20 > element. I=20 > > think its valuable, independent of any desire to align=20 > with geopriv. > >=20 > > Comments? >=20 > I agree. I also agree. Also, this would seem to fulfill one of the things = discussed in the on-demand authorization draft in SIPPING. Cheers, Aki =20 > >=20 > > Thanks, > > Jonathan R. >=20 >=20 >=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-admin@ietf.org Wed Nov 26 10:53:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13577; Wed, 26 Nov 2003 10:53:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1zV-000004-00; Wed, 26 Nov 2003 10:54:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP1zV-0007nc-00; Wed, 26 Nov 2003 10:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1zN-0004Ye-2p; Wed, 26 Nov 2003 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1zF-0004YA-4Q for simple@optimus.ietf.org; Wed, 26 Nov 2003 10:53:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13510 for ; Wed, 26 Nov 2003 10:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1zB-0007mD-00 for simple@ietf.org; Wed, 26 Nov 2003 10:53:50 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AP1zB-0007lC-00 for simple@ietf.org; Wed, 26 Nov 2003 10:53:49 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAQFqiLS017843; Wed, 26 Nov 2003 09:52:45 -0600 (CST) Message-ID: <3FC4CC49.5676F71A@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Ben Campbell , Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:52:41 -0600 Content-Transfer-Encoding: 7bit Hello Robert, Please see comments in-line. Regards, Alex. Robert Sparks wrote: > (speaking from the floor) > > In the presence/IM systems I've been using on a daily basis for > some time now, I do not have a way to say "Allow everybody in > foo.com except bar" and I still find these systems useful. > > On reflection, when using future systems I think I will prefer the model > of explicitly listing those people I wish to authorize over excepting > individuals from a set I cannot control and possibly cannot know. > Even if you want to authorize thousands of users but one or two? That is not an economical use of processing cycles that will be brought to bear in going through that long list of authorized users every time a subscrption is attempted (in my view). > > Thus, I don't think it is absolutely necessary to have that kind of > statement in the initial xcap-auth mechanism. > > I do see the power of having such a statement to some applications > that may consume presence, and I would very much like to have such > a statement available. I think it is acceptable for this functionality > to be an extension of the base xcap-auth tool. > > RjS > > On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > > >>So you have allowed John, Alice, Ben and Adam. That is _not_ > > >>the same as > > >>"Everyone but Bob". For example, what if Carol joins example.com > > >>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will > > >>not include > > >>her, but the "Everyone but Bob rule" would. > > > > > > > > > Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > > > > > > > That assumes you know about Carol. My point is, these two cases are not > > the same thing. You might be able to simulate something like exceptions > > by doing this, if and only if you have full knowledge of the membership > > of example.com. I suspect that will commonly be false. > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Nov 26 10:54:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13660 for ; Wed, 26 Nov 2003 10:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1zY-0004Zg-SO for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 10:54:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQFsCd7017578 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 10:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1zY-0004ZR-O3 for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 10:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13577; Wed, 26 Nov 2003 10:53:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1zV-000004-00; Wed, 26 Nov 2003 10:54:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP1zV-0007nc-00; Wed, 26 Nov 2003 10:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1zN-0004Ye-2p; Wed, 26 Nov 2003 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP1zF-0004YA-4Q for simple@optimus.ietf.org; Wed, 26 Nov 2003 10:53:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13510 for ; Wed, 26 Nov 2003 10:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP1zB-0007mD-00 for simple@ietf.org; Wed, 26 Nov 2003 10:53:50 -0500 Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx with esmtp (Exim 4.12) id 1AP1zB-0007lC-00 for simple@ietf.org; Wed, 26 Nov 2003 10:53:49 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hAQFqiLS017843; Wed, 26 Nov 2003 09:52:45 -0600 (CST) Message-ID: <3FC4CC49.5676F71A@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks CC: Ben Campbell , Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:52:41 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Robert, Please see comments in-line. Regards, Alex. Robert Sparks wrote: > (speaking from the floor) > > In the presence/IM systems I've been using on a daily basis for > some time now, I do not have a way to say "Allow everybody in > foo.com except bar" and I still find these systems useful. > > On reflection, when using future systems I think I will prefer the model > of explicitly listing those people I wish to authorize over excepting > individuals from a set I cannot control and possibly cannot know. > Even if you want to authorize thousands of users but one or two? That is not an economical use of processing cycles that will be brought to bear in going through that long list of authorized users every time a subscrption is attempted (in my view). > > Thus, I don't think it is absolutely necessary to have that kind of > statement in the initial xcap-auth mechanism. > > I do see the power of having such a statement to some applications > that may consume presence, and I would very much like to have such > a statement available. I think it is acceptable for this functionality > to be an extension of the base xcap-auth tool. > > RjS > > On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > > >>So you have allowed John, Alice, Ben and Adam. That is _not_ > > >>the same as > > >>"Everyone but Bob". For example, what if Carol joins example.com > > >>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will > > >>not include > > >>her, but the "Everyone but Bob rule" would. > > > > > > > > > Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > > > > > > > That assumes you know about Carol. My point is, these two cases are not > > the same thing. You might be able to simulate something like exceptions > > by doing this, if and only if you have full knowledge of the membership > > of example.com. I suspect that will commonly be false. > > > > _______________________________________________ > 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-admin@ietf.org Wed Nov 26 10:56:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13963; Wed, 26 Nov 2003 10:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP22J-00008k-00; Wed, 26 Nov 2003 10:57:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP22J-00008f-00; Wed, 26 Nov 2003 10:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP22H-0004hV-FB; Wed, 26 Nov 2003 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP21x-0004gy-Ud for simple@optimus.ietf.org; Wed, 26 Nov 2003 10:56:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13929 for ; Wed, 26 Nov 2003 10:56:26 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP21v-00007k-00 for simple@ietf.org; Wed, 26 Nov 2003 10:56:39 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AP21u-00007V-00 for simple@ietf.org; Wed, 26 Nov 2003 10:56:38 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQFubQ29963 for ; Wed, 26 Nov 2003 17:56:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 17:56:36 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 17:56:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CD@esebe013.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOzknU2vFnGbZrvR6qB4mCp7f6yrgAobJrw To: Cc: , X-OriginalArrivalTime: 26 Nov 2003 15:56:36.0960 (UTC) FILETIME=[DF540E00:01C3B435] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 17:56:36 +0200 Content-Transfer-Encoding: quoted-printable > btw, a small note. Stating tls as authentication mechanism=20 > is actually wrong > since you have to indicate which protocol was used within=20 > the tls handshake, > e.g.,=20 > - Kerberos > - Unilateral pk-based authentication > - Mutual pk-based authentication > - Shared secret authentication > - strong-password based authentication using srp Worse yet, in SIP, the use of TLS tells the presence server nothing = about the actual authenticity of the From field. The From could still be = spoofed by the originator of the SUBSCRIBE, even when the previous hop = (or in fact all of the hops) successfully authenticated itself in TLS. BTW, I agree that enumerating authentication mechanisms in authorization = policy adds no value. Any unauthenticated identity should be treated as = anonymous, as should of course all really anonymous watchers. Cheers, Aki >=20 > ciao > hannes >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com]=20 > > Sent: Dienstag, 25. November 2003 09:20 > > To: bcampbell@dynamicsoft.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] xcap/geopriv alignment issue 4:=20 > authentication > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: 24.November.2003 23:00 > > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: Re: [Simple] xcap/geopriv alignment issue 4:=20 > authentication > > >=20 > > >=20 > > > hisham.khartabil@nokia.com wrote: > > >=20 > > > > Can the user at least have a say in accepting or rejecting > > > the subscription based on the availability of any > > > authentication type. Eg: A user can reject subscriptions that=20 > > > are not authenticated in any way and accept subscriptions=20 > > > that are authenticated, regardless of authentication type. > > >=20 > > > In the absence of _some_ authentication, what is the=20 > value of having > > > authorization policies in the first place? They have no=20 > > > meaning if you=20 > > > cannot put some degree of trust in the requestor identity. > > >=20 > > > I think the email world has proven to us how useful it is to > > > authorize=20 > > > on un-authenticated headers. How useful is a spam filter that=20 > > > relies on=20 > > > the From header? > >=20 > > Either I'm missing your point, or you missed mine. All I said=20 > > was that the user should be able to reject subscriptions if=20 > > they are not authenticated (authentication method is irrelevant). > >=20 > > /Hisham > >=20 > > >=20 > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > >=20 > > > >>-----Original Message----- > > > >>From: simple-admin@ietf.org > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > >>ext Jonathan Rosenberg > > > >>Sent: 24.November.2003 08:13 > > > >>To: Simple WG > > > >>Subject: [Simple] xcap/geopriv alignment issue 4:=20 > authentication > > > >> > > > >> > > > >>Folks, > > > >> > > > >>Currently, xcap-auth defines an authentication condition. > > > This allows > > > >>you to decide whether to accept or reject a subscription > > > based on the > > > >>type of authentication used in the SUBSCRIBE request. > > > >> > > > >>The geopriv policy specification currently has no such=20 > mechanism. > > > >> > > > >>This was discussed during the geopriv meeting in > > > Minneapolis. If you > > > >>think about it for a bit, its not clear how this would=20 > > actually get > > > >>used. Remember, it is end users that will set these=20 > > policies. What=20 > > > >>kind of meaningful information can be provided to a user=20 > > about the=20 > > > >>differences between p-asserted-id and sip-identity and digest=20 > > > >>authentication? What would make a user give permission for=20 > > > >>one type or=20 > > > >>authentication, and not another? Practically speaking, it=20 > > > doesnt seem > > > >>like its easy to use at all. > > > >> > > > >>As a result, I would propose to remove the authentication=20 > > condition > > > >>from xcap-auth. > > > >> > > > >>Comments? > > > >> > > > >>-Jonathan R. > > > >>--=20 > > > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > >>Chief Technology Officer Parsippany, NJ=20 > > > 07054-2711 > > > >>dynamicsoft > > > >>jdrosen@dynamicsoft.com FAX: =20 > (973) 952-5050 > > > >>http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > >>http://www.dynamicsoft.com > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Simple mailing list > > > >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=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 exim@www1.ietf.org Wed Nov 26 10:57:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14031 for ; Wed, 26 Nov 2003 10:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP22N-0004jh-35 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 10:57:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQFv7OD018199 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 10:57:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP22M-0004jS-Vo for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 10:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13963; Wed, 26 Nov 2003 10:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP22J-00008k-00; Wed, 26 Nov 2003 10:57:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP22J-00008f-00; Wed, 26 Nov 2003 10:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP22H-0004hV-FB; Wed, 26 Nov 2003 10:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP21x-0004gy-Ud for simple@optimus.ietf.org; Wed, 26 Nov 2003 10:56:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13929 for ; Wed, 26 Nov 2003 10:56:26 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP21v-00007k-00 for simple@ietf.org; Wed, 26 Nov 2003 10:56:39 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AP21u-00007V-00 for simple@ietf.org; Wed, 26 Nov 2003 10:56:38 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQFubQ29963 for ; Wed, 26 Nov 2003 17:56:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 17:56:36 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 17:56:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] xcap/geopriv alignment issue 4: authentication Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CD@esebe013.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcOzknU2vFnGbZrvR6qB4mCp7f6yrgAobJrw To: Cc: , X-OriginalArrivalTime: 26 Nov 2003 15:56:36.0960 (UTC) FILETIME=[DF540E00:01C3B435] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 17:56:36 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > btw, a small note. Stating tls as authentication mechanism=20 > is actually wrong > since you have to indicate which protocol was used within=20 > the tls handshake, > e.g.,=20 > - Kerberos > - Unilateral pk-based authentication > - Mutual pk-based authentication > - Shared secret authentication > - strong-password based authentication using srp Worse yet, in SIP, the use of TLS tells the presence server nothing = about the actual authenticity of the From field. The From could still be = spoofed by the originator of the SUBSCRIBE, even when the previous hop = (or in fact all of the hops) successfully authenticated itself in TLS. BTW, I agree that enumerating authentication mechanisms in authorization = policy adds no value. Any unauthenticated identity should be treated as = anonymous, as should of course all really anonymous watchers. Cheers, Aki >=20 > ciao > hannes >=20 > > -----Original Message----- > > From: hisham.khartabil@nokia.com=20 > [mailto:hisham.khartabil@nokia.com]=20 > > Sent: Dienstag, 25. November 2003 09:20 > > To: bcampbell@dynamicsoft.com > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > Subject: RE: [Simple] xcap/geopriv alignment issue 4:=20 > authentication > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: 24.November.2003 23:00 > > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > > Cc: jdrosen@dynamicsoft.com; simple@ietf.org > > > Subject: Re: [Simple] xcap/geopriv alignment issue 4:=20 > authentication > > >=20 > > >=20 > > > hisham.khartabil@nokia.com wrote: > > >=20 > > > > Can the user at least have a say in accepting or rejecting > > > the subscription based on the availability of any > > > authentication type. Eg: A user can reject subscriptions that=20 > > > are not authenticated in any way and accept subscriptions=20 > > > that are authenticated, regardless of authentication type. > > >=20 > > > In the absence of _some_ authentication, what is the=20 > value of having > > > authorization policies in the first place? They have no=20 > > > meaning if you=20 > > > cannot put some degree of trust in the requestor identity. > > >=20 > > > I think the email world has proven to us how useful it is to > > > authorize=20 > > > on un-authenticated headers. How useful is a spam filter that=20 > > > relies on=20 > > > the From header? > >=20 > > Either I'm missing your point, or you missed mine. All I said=20 > > was that the user should be able to reject subscriptions if=20 > > they are not authenticated (authentication method is irrelevant). > >=20 > > /Hisham > >=20 > > >=20 > > > >=20 > > > > Regards, > > > > Hisham > > > >=20 > > > >=20 > > > >>-----Original Message----- > > > >>From: simple-admin@ietf.org > > > [mailto:simple-admin@ietf.org]On Behalf Of > > > >>ext Jonathan Rosenberg > > > >>Sent: 24.November.2003 08:13 > > > >>To: Simple WG > > > >>Subject: [Simple] xcap/geopriv alignment issue 4:=20 > authentication > > > >> > > > >> > > > >>Folks, > > > >> > > > >>Currently, xcap-auth defines an authentication condition. > > > This allows > > > >>you to decide whether to accept or reject a subscription > > > based on the > > > >>type of authentication used in the SUBSCRIBE request. > > > >> > > > >>The geopriv policy specification currently has no such=20 > mechanism. > > > >> > > > >>This was discussed during the geopriv meeting in > > > Minneapolis. If you > > > >>think about it for a bit, its not clear how this would=20 > > actually get > > > >>used. Remember, it is end users that will set these=20 > > policies. What=20 > > > >>kind of meaningful information can be provided to a user=20 > > about the=20 > > > >>differences between p-asserted-id and sip-identity and digest=20 > > > >>authentication? What would make a user give permission for=20 > > > >>one type or=20 > > > >>authentication, and not another? Practically speaking, it=20 > > > doesnt seem > > > >>like its easy to use at all. > > > >> > > > >>As a result, I would propose to remove the authentication=20 > > condition > > > >>from xcap-auth. > > > >> > > > >>Comments? > > > >> > > > >>-Jonathan R. > > > >>--=20 > > > >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > >>Chief Technology Officer Parsippany, NJ=20 > > > 07054-2711 > > > >>dynamicsoft > > > >>jdrosen@dynamicsoft.com FAX: =20 > (973) 952-5050 > > > >>http://www.jdrosen.net PHONE:=20 > (973) 952-5000 > > > >>http://www.dynamicsoft.com > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Simple mailing list > > > >>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > > >> > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >=20 >=20 >=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-admin@ietf.org Wed Nov 26 16:25:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28745; Wed, 26 Nov 2003 16:25:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7Aq-00051H-00; Wed, 26 Nov 2003 16:26:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP7Ah-00051B-00; Wed, 26 Nov 2003 16:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7Ae-0003bh-QH; Wed, 26 Nov 2003 16:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP79u-0003ax-EF for simple@optimus.ietf.org; Wed, 26 Nov 2003 16:25:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28732 for ; Wed, 26 Nov 2003 16:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP79s-00050v-00 for simple@ietf.org; Wed, 26 Nov 2003 16:25:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AP79r-00050n-00 for simple@ietf.org; Wed, 26 Nov 2003 16:25:11 -0500 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAQLOfca022883; Wed, 26 Nov 2003 16:24:42 -0500 (EST) Message-ID: <3FC51A12.8060101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events References: <475FF955A05DD411980D00508B6D5FB00439EF2E@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF2E@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 16:24:34 -0500 Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > >>> Is it not the case that presence servers supporting the >>> "presence" event, probably (i.e. SHOULD strength) also support >>> the "presence.winfo" event template. >> >> We have never made that a requirement anywhere. I'm not sure its >> IETF's job to do that. > > > I understood the following text from section 4.6 of > draft-ietf-simple-winfo-package-05 specified this requirement. Have > I misread this. > > "It is RECOMMENDED that user A be allowed to subscribe to their own > watcher information for any package. This is true recursively, so > that it is RECOMMENDED that a user be able to subscribe to the > watcher information for their watcher information for any package." This text does not mean that, if you support presence, you need to support winfo. It means that, for any package that the server might support, it should allow a user to subscribe to winfo for that package (assuming of course winfo is supported). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Nov 26 16:26:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28780 for ; Wed, 26 Nov 2003 16:26:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7As-0003fs-TL for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 16:26:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQLQEFh014120 for simple-archive@odin.ietf.org; Wed, 26 Nov 2003 16:26:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7As-0003ff-QO for simple-web-archive@optimus.ietf.org; Wed, 26 Nov 2003 16:26:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28745; Wed, 26 Nov 2003 16:25:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP7Aq-00051H-00; Wed, 26 Nov 2003 16:26:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AP7Ah-00051B-00; Wed, 26 Nov 2003 16:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP7Ae-0003bh-QH; Wed, 26 Nov 2003 16:26:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AP79u-0003ax-EF for simple@optimus.ietf.org; Wed, 26 Nov 2003 16:25:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28732 for ; Wed, 26 Nov 2003 16:25:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP79s-00050v-00 for simple@ietf.org; Wed, 26 Nov 2003 16:25:12 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AP79r-00050n-00 for simple@ietf.org; Wed, 26 Nov 2003 16:25:11 -0500 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAQLOfca022883; Wed, 26 Nov 2003 16:24:42 -0500 (EST) Message-ID: <3FC51A12.8060101@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: Adam Roach , simple@ietf.org Subject: Re: [Simple] Question on draft-ietf-simple-presence-10 and Allow- Events References: <475FF955A05DD411980D00508B6D5FB00439EF2E@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF2E@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 16:24:34 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Drage, Keith (Keith) wrote: > >>> Is it not the case that presence servers supporting the >>> "presence" event, probably (i.e. SHOULD strength) also support >>> the "presence.winfo" event template. >> >> We have never made that a requirement anywhere. I'm not sure its >> IETF's job to do that. > > > I understood the following text from section 4.6 of > draft-ietf-simple-winfo-package-05 specified this requirement. Have > I misread this. > > "It is RECOMMENDED that user A be allowed to subscribe to their own > watcher information for any package. This is true recursively, so > that it is RECOMMENDED that a user be able to subscribe to the > watcher information for their watcher information for any package." This text does not mean that, if you support presence, you need to support winfo. It means that, for any package that the server might support, it should allow a user to subscribe to winfo for that package (assuming of course winfo is supported). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 27 04:16:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01095; Thu, 27 Nov 2003 04:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIFu-0005W4-00; Thu, 27 Nov 2003 04:16:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APIFu-0005Vy-00; Thu, 27 Nov 2003 04:16:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIFl-0007Jo-Eo; Thu, 27 Nov 2003 04:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIFD-0007Gx-7C for simple@optimus.ietf.org; Thu, 27 Nov 2003 04:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01081 for ; Thu, 27 Nov 2003 04:15:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIFA-0005Vn-00 for simple@ietf.org; Thu, 27 Nov 2003 04:15:24 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1APIF9-0005VX-00 for simple@ietf.org; Thu, 27 Nov 2003 04:15:23 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-20.tower-49.messagelabs.com!1069924482!479050 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 8577 invoked from network); 27 Nov 2003 09:14:42 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-20.tower-49.messagelabs.com with SMTP; 27 Nov 2003 09:14:42 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Thu, 27 Nov 2003 09:17:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Comments on message-sessions-02 - message retry Message-ID: <45730E094814E44488F789C1CDED27AE0219B127@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcO0m0nDT/k1b4YjT4eSgPUKzJA6iAAKR/AA From: "Chris Boulton" To: "Paul Kyzivat" , "Ben Campbell" Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Nov 2003 09:14:38 -0000 Content-Transfer-Encoding: quoted-printable <> >-----Original=20Message----- >From:=20Paul=20Kyzivat=20[mailto:pkyzivat@cisco.com] >Sent:=2007=20November=202003=2023:10 >To:=20Ben=20Campbell >Cc:=20hisham.khartabil@nokia.com;=20simple@ietf.org >Subject:=20Re:=20[Simple]=20Comments=20on=20message-sessions-02=20-=20mes= sage=20retry > >inline... > >Ben=20Campbell=20wrote: >>=20Paul=20Kyzivat=20wrote: >> >>>=20hisham.khartabil@nokia.com=20wrote: >>> >>>> >>>>=20-=20Section=207.4.3: >>>>=20=20=20=20-=20In=20step=205=20"The=20endpoint=20MAY=20attempt=20to=20= send=20the=20message content >>>>=20again" >>> >>> >>>=20=20>=20=20=20=20=20=20Should=20we=20remove=20this=20text?=20If=20the= =20message=20sending=20fails,=20so >>>=20be=20it. >>>=20=20>=20=20=20=20=20=20The=20user=20can=20choose=20to=20send=20it=20a= gain.=20This=20avoids=20the=20very >>>=20large=20message >>>=20=20>=20=20=20=20=20=20being=20sent=20again=20(long=20messages=20have= =20the=20potential=20to falsely >>>=20timing=20out >>>=20=20>=20=20=20=20=20=20and=20the=20sender=20gets=20a=20500=20response= ). >>> >>>=20I=20agree=20this=20should=20go.=20We=20may=20want=20to=20discuss=20p= ossibility=20of >>>=20establishing=20a=20replacement=20media=20session=20and=20then=20retr= ying=20the message >>>=20there.=20In=20that=20case=20I=20think=20we=20perhaps=20should=20make= =20it=20permissible for >>>=20the=20retry=20to=20use=20the=20same=20TR-ID.=20It=20is=20then=20opti= onal=20whether=20the >>>=20recipient=20detects=20the=20duplicate=20or=20not. >> >>=20I=20don't=20mind=20mentioning=20that=20some=20implementations=20might= =20choose=20to create >>=20a=20new=20session=20and=20attempt=20to=20resume=20a=20conversation--b= ut=20I=20do=20not=20want to >>=20imply=20that=20it=20should=20or=20should=20not=20be=20done. > >I=20agree=20it=20should=20be=20an=20application=20issue=20whether=20to=20= do=20this. > >=20>=20As=20far=20as=20retrying=20the=20same >>=20TR-ID,=20I=20do=20not=20think=20that=20is=20useful=20unless=20we=20st= rengthen=20the uniqueness >>=20requirements=20for=20TR-ID,=20and=20recommend=20some=20period=20of=20= time=20that=20an >>=20endpoint=20should=20remember=20previous=20ones=20it=20had=20seen. > >I'm=20not=20certain=20a=20time=20period=20is=20really=20necessary.=20I=20= think=20this=20can=20be >local=20option. > >Even=20uniqueness=20across=20streams=20isn't=20*required*,=20though=20it=20= would=20be >helpful.=20Instead,=20we=20can=20simply=20introduce=20an=20error=20respon= se=20to=20be=20used >when=20a=20duplicate=20is=20detected=20and=20supressed.=20If=20it=20was=20= supressed=20in error >because=20the=20sender=20duplicated=20a=20TR-ID=20from=20another=20stream= ,=20the=20sender >would=20then=20know=20to=20recover. [Chris=20Boulton]This=20seems=20by=20far=20the=20most=20straight=20forward= =20solution.=20=20I certainly=20think=20that=20we=20should=20encourage=20uniqueness=20across=20= streams=20-=20I see=20this=20causing=20problems.=20=20As=20for=20the=20amount=20of=20time=20= that=20a=20TRID=20is 'remembered'=20-=20couldn't=20it=20just=20be=20for=20the=20duration=20of=20= the=20SIP=20dialog?=20 > >But=20I=20agree=20that=20some=20further=20clarification=20on=20TR-ID=20un= iqueness=20could be >helpful. > >>>=20This=20addresses=20the=20case=20where=20a=20relay=20crashes=20in=20a= n=20ungraceful=20way. >>> >>>>=20=20=20=20-=20Open=20issue:=20NO. >>> >>>=20I=20guess=20what=20I=20am=20proposing=20is=20YES,=20but=20with=20a=20= weak=20mechanism=20- >>>=20neither=20side=20is=20*required*=20to=20enable=20duplicate=20suppres= sion,=20but=20the >>>=20mechanism=20is=20there=20if=20both=20sides=20choose=20to=20use=20it.= >> >>=20I=20assume=20the=20weak=20mechanism=20to=20which=20you=20refer=20is=20= the=20TR-ID=20approach >>=20mentioned=20above.=20See=20my=20comments=20above. > >yes. > >=09Paul > > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 27 04:16:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01114 for ; Thu, 27 Nov 2003 04:16:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIFy-0007Kq-Pt for simple-archive@odin.ietf.org; Thu, 27 Nov 2003 04:16:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR9GEiT028197 for simple-archive@odin.ietf.org; Thu, 27 Nov 2003 04:16:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIFy-0007Ki-10 for simple-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 04:16:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01095; Thu, 27 Nov 2003 04:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIFu-0005W4-00; Thu, 27 Nov 2003 04:16:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APIFu-0005Vy-00; Thu, 27 Nov 2003 04:16:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIFl-0007Jo-Eo; Thu, 27 Nov 2003 04:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APIFD-0007Gx-7C for simple@optimus.ietf.org; Thu, 27 Nov 2003 04:15:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01081 for ; Thu, 27 Nov 2003 04:15:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APIFA-0005Vn-00 for simple@ietf.org; Thu, 27 Nov 2003 04:15:24 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1APIF9-0005VX-00 for simple@ietf.org; Thu, 27 Nov 2003 04:15:23 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-20.tower-49.messagelabs.com!1069924482!479050 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 8577 invoked from network); 27 Nov 2003 09:14:42 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-20.tower-49.messagelabs.com with SMTP; 27 Nov 2003 09:14:42 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Thu, 27 Nov 2003 09:17:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Comments on message-sessions-02 - message retry Message-ID: <45730E094814E44488F789C1CDED27AE0219B127@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcO0m0nDT/k1b4YjT4eSgPUKzJA6iAAKR/AA From: "Chris Boulton" To: "Paul Kyzivat" , "Ben Campbell" Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Nov 2003 09:14:38 -0000 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable <> >-----Original=20Message----- >From:=20Paul=20Kyzivat=20[mailto:pkyzivat@cisco.com] >Sent:=2007=20November=202003=2023:10 >To:=20Ben=20Campbell >Cc:=20hisham.khartabil@nokia.com;=20simple@ietf.org >Subject:=20Re:=20[Simple]=20Comments=20on=20message-sessions-02=20-=20mes= sage=20retry > >inline... > >Ben=20Campbell=20wrote: >>=20Paul=20Kyzivat=20wrote: >> >>>=20hisham.khartabil@nokia.com=20wrote: >>> >>>> >>>>=20-=20Section=207.4.3: >>>>=20=20=20=20-=20In=20step=205=20"The=20endpoint=20MAY=20attempt=20to=20= send=20the=20message content >>>>=20again" >>> >>> >>>=20=20>=20=20=20=20=20=20Should=20we=20remove=20this=20text?=20If=20the= =20message=20sending=20fails,=20so >>>=20be=20it. >>>=20=20>=20=20=20=20=20=20The=20user=20can=20choose=20to=20send=20it=20a= gain.=20This=20avoids=20the=20very >>>=20large=20message >>>=20=20>=20=20=20=20=20=20being=20sent=20again=20(long=20messages=20have= =20the=20potential=20to falsely >>>=20timing=20out >>>=20=20>=20=20=20=20=20=20and=20the=20sender=20gets=20a=20500=20response= ). >>> >>>=20I=20agree=20this=20should=20go.=20We=20may=20want=20to=20discuss=20p= ossibility=20of >>>=20establishing=20a=20replacement=20media=20session=20and=20then=20retr= ying=20the message >>>=20there.=20In=20that=20case=20I=20think=20we=20perhaps=20should=20make= =20it=20permissible for >>>=20the=20retry=20to=20use=20the=20same=20TR-ID.=20It=20is=20then=20opti= onal=20whether=20the >>>=20recipient=20detects=20the=20duplicate=20or=20not. >> >>=20I=20don't=20mind=20mentioning=20that=20some=20implementations=20might= =20choose=20to create >>=20a=20new=20session=20and=20attempt=20to=20resume=20a=20conversation--b= ut=20I=20do=20not=20want to >>=20imply=20that=20it=20should=20or=20should=20not=20be=20done. > >I=20agree=20it=20should=20be=20an=20application=20issue=20whether=20to=20= do=20this. > >=20>=20As=20far=20as=20retrying=20the=20same >>=20TR-ID,=20I=20do=20not=20think=20that=20is=20useful=20unless=20we=20st= rengthen=20the uniqueness >>=20requirements=20for=20TR-ID,=20and=20recommend=20some=20period=20of=20= time=20that=20an >>=20endpoint=20should=20remember=20previous=20ones=20it=20had=20seen. > >I'm=20not=20certain=20a=20time=20period=20is=20really=20necessary.=20I=20= think=20this=20can=20be >local=20option. > >Even=20uniqueness=20across=20streams=20isn't=20*required*,=20though=20it=20= would=20be >helpful.=20Instead,=20we=20can=20simply=20introduce=20an=20error=20respon= se=20to=20be=20used >when=20a=20duplicate=20is=20detected=20and=20supressed.=20If=20it=20was=20= supressed=20in error >because=20the=20sender=20duplicated=20a=20TR-ID=20from=20another=20stream= ,=20the=20sender >would=20then=20know=20to=20recover. [Chris=20Boulton]This=20seems=20by=20far=20the=20most=20straight=20forward= =20solution.=20=20I certainly=20think=20that=20we=20should=20encourage=20uniqueness=20across=20= streams=20-=20I see=20this=20causing=20problems.=20=20As=20for=20the=20amount=20of=20time=20= that=20a=20TRID=20is 'remembered'=20-=20couldn't=20it=20just=20be=20for=20the=20duration=20of=20= the=20SIP=20dialog?=20 > >But=20I=20agree=20that=20some=20further=20clarification=20on=20TR-ID=20un= iqueness=20could be >helpful. > >>>=20This=20addresses=20the=20case=20where=20a=20relay=20crashes=20in=20a= n=20ungraceful=20way. >>> >>>>=20=20=20=20-=20Open=20issue:=20NO. >>> >>>=20I=20guess=20what=20I=20am=20proposing=20is=20YES,=20but=20with=20a=20= weak=20mechanism=20- >>>=20neither=20side=20is=20*required*=20to=20enable=20duplicate=20suppres= sion,=20but=20the >>>=20mechanism=20is=20there=20if=20both=20sides=20choose=20to=20use=20it.= >> >>=20I=20assume=20the=20weak=20mechanism=20to=20which=20you=20refer=20is=20= the=20TR-ID=20approach >>=20mentioned=20above.=20See=20my=20comments=20above. > >yes. > >=09Paul > > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Nov 27 10:20:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09953; Thu, 27 Nov 2003 10:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APNx6-0001UK-00; Thu, 27 Nov 2003 10:21:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APNx5-0001UH-00; Thu, 27 Nov 2003 10:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNx0-0005i1-2b; Thu, 27 Nov 2003 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNwS-0005hW-Rl for simple@optimus.ietf.org; Thu, 27 Nov 2003 10:20:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09944 for ; Thu, 27 Nov 2003 10:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APNwQ-0001U1-00 for simple@ietf.org; Thu, 27 Nov 2003 10:20:26 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1APNwP-0001Tw-00 for simple@ietf.org; Thu, 27 Nov 2003 10:20:26 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hARFKNI2003392; Thu, 27 Nov 2003 16:20:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Nov 2003 16:20:23 +0100 Message-ID: From: "Vesa Torvinen (JO/LMF)" To: "'Jonathan Rosenberg'" , "'Simple WG'" Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Nov 2003 16:19:01 +0100 Hi, [Tried to send something on this before but haven't seen my mail on the list... this is the second try.] I think this was originally related to a use case where a policy would define that "anyone that knows the password is allowed to subscribe". The presentity wouldn't exactly be interested in authentication in terms of identities (the watcher could be "anonymous") - just to be sure that all authorized watchers know the password. This use case is similar to the policies currently used in phone conferencing systems, i.e. the participant just needs to know the conference id, and related password - and not really to authenticate himself in terms of real identity. One problem is, of course, that the password should be specific to the presentity, e.g. "realm=alice@domain.com", not to the "realm=domain.com" as a whole. There has also been some discussion in 3GPP/SA3 on having an option for using a password based authentication in addition to the P-Asserted-Identity header based "authentication". Not all people like this idea, however, it could provide some additional security for 3GPP IP multimedia subsystem. For example, HTTP Digest AKA (that is used to create the P-Asserted-Identity) does not really authenticate the end-user - it authenticates the subscription/device. I agree that forcing the use of S/MIME, TLS or P-Asserted-Identity is not really meaningful. However, having policies that mandate the use of HTTP Digest (or some other password based mechanism) may still be useful. Vesa -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: 24. marraskuuta 2003 8:13 To: Simple WG Subject: [Simple] xcap/geopriv alignment issue 4: authentication Folks, Currently, xcap-auth defines an authentication condition. This allows you to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request. The geopriv policy specification currently has no such mechanism. This was discussed during the geopriv meeting in Minneapolis. If you think about it for a bit, its not clear how this would actually get used. Remember, it is end users that will set these policies. What kind of meaningful information can be provided to a user about the differences between p-asserted-id and sip-identity and digest authentication? What would make a user give permission for one type or authentication, and not another? Practically speaking, it doesnt seem like its easy to use at all. As a result, I would propose to remove the authentication condition from xcap-auth. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Nov 27 10:22:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10003 for ; Thu, 27 Nov 2003 10:22:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNx9-0005in-0w for simple-archive@odin.ietf.org; Thu, 27 Nov 2003 10:21:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARFLAR3021992 for simple-archive@odin.ietf.org; Thu, 27 Nov 2003 10:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNx8-0005id-Tq for simple-web-archive@optimus.ietf.org; Thu, 27 Nov 2003 10:21:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09953; Thu, 27 Nov 2003 10:20:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APNx6-0001UK-00; Thu, 27 Nov 2003 10:21:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APNx5-0001UH-00; Thu, 27 Nov 2003 10:21:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNx0-0005i1-2b; Thu, 27 Nov 2003 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APNwS-0005hW-Rl for simple@optimus.ietf.org; Thu, 27 Nov 2003 10:20:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09944 for ; Thu, 27 Nov 2003 10:20:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APNwQ-0001U1-00 for simple@ietf.org; Thu, 27 Nov 2003 10:20:26 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1APNwP-0001Tw-00 for simple@ietf.org; Thu, 27 Nov 2003 10:20:26 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hARFKNI2003392; Thu, 27 Nov 2003 16:20:23 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Nov 2003 16:20:23 +0100 Message-ID: From: "Vesa Torvinen (JO/LMF)" To: "'Jonathan Rosenberg'" , "'Simple WG'" Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 27 Nov 2003 16:19:01 +0100 Hi, [Tried to send something on this before but haven't seen my mail on the list... this is the second try.] I think this was originally related to a use case where a policy would define that "anyone that knows the password is allowed to subscribe". The presentity wouldn't exactly be interested in authentication in terms of identities (the watcher could be "anonymous") - just to be sure that all authorized watchers know the password. This use case is similar to the policies currently used in phone conferencing systems, i.e. the participant just needs to know the conference id, and related password - and not really to authenticate himself in terms of real identity. One problem is, of course, that the password should be specific to the presentity, e.g. "realm=alice@domain.com", not to the "realm=domain.com" as a whole. There has also been some discussion in 3GPP/SA3 on having an option for using a password based authentication in addition to the P-Asserted-Identity header based "authentication". Not all people like this idea, however, it could provide some additional security for 3GPP IP multimedia subsystem. For example, HTTP Digest AKA (that is used to create the P-Asserted-Identity) does not really authenticate the end-user - it authenticates the subscription/device. I agree that forcing the use of S/MIME, TLS or P-Asserted-Identity is not really meaningful. However, having policies that mandate the use of HTTP Digest (or some other password based mechanism) may still be useful. Vesa -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: 24. marraskuuta 2003 8:13 To: Simple WG Subject: [Simple] xcap/geopriv alignment issue 4: authentication Folks, Currently, xcap-auth defines an authentication condition. This allows you to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request. The geopriv policy specification currently has no such mechanism. This was discussed during the geopriv meeting in Minneapolis. If you think about it for a bit, its not clear how this would actually get used. Remember, it is end users that will set these policies. What kind of meaningful information can be provided to a user about the differences between p-asserted-id and sip-identity and digest authentication? What would make a user give permission for one type or authentication, and not another? Practically speaking, it doesnt seem like its easy to use at all. As a result, I would propose to remove the authentication condition from xcap-auth. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 28 11:52:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03549; Fri, 28 Nov 2003 11:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlqo-00052f-00; Fri, 28 Nov 2003 11:52:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APlqo-00052a-00; Fri, 28 Nov 2003 11:52:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlqa-00056Q-W3; Fri, 28 Nov 2003 11:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlpo-000564-Qo for simple@optimus.ietf.org; Fri, 28 Nov 2003 11:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03515 for ; Fri, 28 Nov 2003 11:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlpn-00051Q-00 for simple@ietf.org; Fri, 28 Nov 2003 11:51:11 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1APlpm-000512-00 for simple@ietf.org; Fri, 28 Nov 2003 11:51:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hASGoSd07819; Fri, 28 Nov 2003 10:50:28 -0600 Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions From: Robert Sparks To: Ben Campbell Cc: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: <3FC4B951.2090508@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> <3FC4B951.2090508@dynamicsoft.com> Content-Type: text/plain Message-Id: <1070038227.935.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Nov 2003 10:50:27 -0600 Content-Transfer-Encoding: 7bit On Wed, 2003-11-26 at 08:31, Ben Campbell wrote: > Robert Sparks wrote: > > > (speaking from the floor) > > > > In the presence/IM systems I've been using on a daily basis for > > some time now, I do not have a way to say "Allow everybody in > > foo.com except bar" and I still find these systems useful. > > I do have to point out that most of the existing, big commercially > deployed systems, are single-domain, non-interoperable systems. We make > due with them because that is what exists. I did not think that is what > we are trying to build here. No, but the question starting this thread is whether or not it would be acceptable to have a base authorization system that didn't support exceptions. My point is that there are environments where such a system would be useful. (And I don't think the single-domain/non-interoperable characteristics of the existing systems I refer to is pertainant to that statement.) > Let me back off from saying you cannot build a useful system without > exceptions. Let me instead state that I have endured a number of > customer requests for authorization models that cannot be implemented > without exceptions. Is there something in this set of requests that would make having exceptions as an extension to the core protocol unacceptable? > > > > On reflection, when using future systems I think I will prefer the model > > of explicitly listing those people I wish to authorize over excepting > > individuals from a set I cannot control and possibly cannot know. > > > > Thus, I don't think it is absolutely necessary to have that kind of > > statement in the initial xcap-auth mechanism. > > > > Out of curiosity, do you see it necessary to be able to say a rule > applies to a domain at all? Or to generalize, to any "group" where > membership is determined when the rule is applied, rather than when it > is created? Useful. Useful enough that I want a system that supports the concept. But absolutely necessary? No. A core authorization system that did not support this concept would still be useful. > > I do see the power of having such a statement to some applications > > that may consume presence, and I would very much like to have such > > a statement available. I think it is acceptable for this functionality > > to be an extension of the base xcap-auth tool. > > > > RjS > > > > On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > > > >>>>So you have allowed John, Alice, Ben and Adam. That is _not_ > >>>>the same as > >>>>"Everyone but Bob". For example, what if Carol joins example.com > >>>>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will > >>>>not include > >>>>her, but the "Everyone but Bob rule" would. > >>> > >>> > >>>Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > >>> > >> > >>That assumes you know about Carol. My point is, these two cases are not > >>the same thing. You might be able to simulate something like exceptions > >>by doing this, if and only if you have full knowledge of the membership > >>of example.com. I suspect that will commonly be false. > >> > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 28 11:52:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03604 for ; Fri, 28 Nov 2003 11:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlqq-00058t-GV for simple-archive@odin.ietf.org; Fri, 28 Nov 2003 11:52:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASGqGQ3019763 for simple-archive@odin.ietf.org; Fri, 28 Nov 2003 11:52:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlqq-00058g-DO for simple-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 11:52:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03549; Fri, 28 Nov 2003 11:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlqo-00052f-00; Fri, 28 Nov 2003 11:52:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APlqo-00052a-00; Fri, 28 Nov 2003 11:52:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlqa-00056Q-W3; Fri, 28 Nov 2003 11:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlpo-000564-Qo for simple@optimus.ietf.org; Fri, 28 Nov 2003 11:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03515 for ; Fri, 28 Nov 2003 11:50:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlpn-00051Q-00 for simple@ietf.org; Fri, 28 Nov 2003 11:51:11 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1APlpm-000512-00 for simple@ietf.org; Fri, 28 Nov 2003 11:51:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hASGoSd07819; Fri, 28 Nov 2003 10:50:28 -0600 Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions From: Robert Sparks To: Ben Campbell Cc: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: <3FC4B951.2090508@dynamicsoft.com> References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> <3FC4B951.2090508@dynamicsoft.com> Content-Type: text/plain Message-Id: <1070038227.935.18.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Nov 2003 10:50:27 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-11-26 at 08:31, Ben Campbell wrote: > Robert Sparks wrote: > > > (speaking from the floor) > > > > In the presence/IM systems I've been using on a daily basis for > > some time now, I do not have a way to say "Allow everybody in > > foo.com except bar" and I still find these systems useful. > > I do have to point out that most of the existing, big commercially > deployed systems, are single-domain, non-interoperable systems. We make > due with them because that is what exists. I did not think that is what > we are trying to build here. No, but the question starting this thread is whether or not it would be acceptable to have a base authorization system that didn't support exceptions. My point is that there are environments where such a system would be useful. (And I don't think the single-domain/non-interoperable characteristics of the existing systems I refer to is pertainant to that statement.) > Let me back off from saying you cannot build a useful system without > exceptions. Let me instead state that I have endured a number of > customer requests for authorization models that cannot be implemented > without exceptions. Is there something in this set of requests that would make having exceptions as an extension to the core protocol unacceptable? > > > > On reflection, when using future systems I think I will prefer the model > > of explicitly listing those people I wish to authorize over excepting > > individuals from a set I cannot control and possibly cannot know. > > > > Thus, I don't think it is absolutely necessary to have that kind of > > statement in the initial xcap-auth mechanism. > > > > Out of curiosity, do you see it necessary to be able to say a rule > applies to a domain at all? Or to generalize, to any "group" where > membership is determined when the rule is applied, rather than when it > is created? Useful. Useful enough that I want a system that supports the concept. But absolutely necessary? No. A core authorization system that did not support this concept would still be useful. > > I do see the power of having such a statement to some applications > > that may consume presence, and I would very much like to have such > > a statement available. I think it is acceptable for this functionality > > to be an extension of the base xcap-auth tool. > > > > RjS > > > > On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: > > > >>>>So you have allowed John, Alice, Ben and Adam. That is _not_ > >>>>the same as > >>>>"Everyone but Bob". For example, what if Carol joins example.com > >>>>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will > >>>>not include > >>>>her, but the "Everyone but Bob rule" would. > >>> > >>> > >>>Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. > >>> > >> > >>That assumes you know about Carol. My point is, these two cases are not > >>the same thing. You might be able to simulate something like exceptions > >>by doing this, if and only if you have full knowledge of the membership > >>of example.com. I suspect that will commonly be false. > >> > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 28 11:56:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03725; Fri, 28 Nov 2003 11:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlvU-00057l-00; Fri, 28 Nov 2003 11:57:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APlvT-00057i-00; Fri, 28 Nov 2003 11:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlvQ-0005NH-HZ; Fri, 28 Nov 2003 11:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlv8-0005N1-Vr for simple@optimus.ietf.org; Fri, 28 Nov 2003 11:56:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03714 for ; Fri, 28 Nov 2003 11:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlv7-00057K-00 for simple@ietf.org; Fri, 28 Nov 2003 11:56:41 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1APlv6-00056y-00 for simple@ietf.org; Fri, 28 Nov 2003 11:56:41 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-20.tower-49.messagelabs.com!1070038559!500486 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 21105 invoked from network); 28 Nov 2003 16:55:59 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-20.tower-49.messagelabs.com with SMTP; 28 Nov 2003 16:55:59 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Fri, 28 Nov 2003 16:58:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Comments on message-sessions-02 - message retry Message-ID: <45730E094814E44488F789C1CDED27AE01E22EDB@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcO1z9qEP+1CL13GTzaRP1NQra+prgAAGmWg From: "Chris Boulton" To: "Ben Campbell" , "Paul Kyzivat" Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Nov 2003 16:55:51 -0000 Content-Transfer-Encoding: quoted-printable >-----Original=20Message----- >From:=20Ben=20Campbell=20[mailto:bcampbell@dynamicsoft.com] >Sent:=2010=20November=202003=2017:09 >To:=20Paul=20Kyzivat >Cc:=20hisham.khartabil@nokia.com;=20simple@ietf.org >Subject:=20Re:=20[Simple]=20Comments=20on=20message-sessions-02=20-=20mes= sage=20retry > >Paul=20Kyzivat=20wrote: > >[...] > >> >>=20I'm=20not=20certain=20a=20time=20period=20is=20really=20necessary.=20= I=20think=20this=20can be >>=20local=20option. >> >>=20Even=20uniqueness=20across=20streams=20isn't=20*required*,=20though=20= it=20would=20be >>=20helpful.=20Instead,=20we=20can=20simply=20introduce=20an=20error=20re= sponse=20to=20be used >>=20when=20a=20duplicate=20is=20detected=20and=20supressed.=20If=20it=20w= as=20supressed=20in error >>=20because=20the=20sender=20duplicated=20a=20TR-ID=20from=20another=20st= ream,=20the=20sender >>=20would=20then=20know=20to=20recover. >> >>=20But=20I=20agree=20that=20some=20further=20clarification=20on=20TR-ID=20= uniqueness=20could be >>=20helpful. >> > >If=20TR-ID=20is=20not=20required=20to=20be=20unique=20across=20sessions,=20= and=20you=20allow >clients=20to=20attempt=20to=20find=20duplicate=20messages=20using=20TR-ID= =20across >sessions,=20then=20you=20introduce=20the=20possibility=20of=20false=20det= ection=20caused >by=20TR-ID=20collisions.=20This=20seems=20bad=20to=20me. > [Chris=20Boulton]=20I=20totally=20agree. > > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 28 11:57:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03745 for ; Fri, 28 Nov 2003 11:57:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlvV-0005OB-Vs for simple-archive@odin.ietf.org; Fri, 28 Nov 2003 11:57:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASGv5la020709 for simple-archive@odin.ietf.org; Fri, 28 Nov 2003 11:57:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlvV-0005Nw-RH for simple-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 11:57:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03725; Fri, 28 Nov 2003 11:56:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlvU-00057l-00; Fri, 28 Nov 2003 11:57:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APlvT-00057i-00; Fri, 28 Nov 2003 11:57:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlvQ-0005NH-HZ; Fri, 28 Nov 2003 11:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APlv8-0005N1-Vr for simple@optimus.ietf.org; Fri, 28 Nov 2003 11:56:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03714 for ; Fri, 28 Nov 2003 11:56:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APlv7-00057K-00 for simple@ietf.org; Fri, 28 Nov 2003 11:56:41 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1APlv6-00056y-00 for simple@ietf.org; Fri, 28 Nov 2003 11:56:41 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-20.tower-49.messagelabs.com!1070038559!500486 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 21105 invoked from network); 28 Nov 2003 16:55:59 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-20.tower-49.messagelabs.com with SMTP; 28 Nov 2003 16:55:59 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Fri, 28 Nov 2003 16:58:32 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] Comments on message-sessions-02 - message retry Message-ID: <45730E094814E44488F789C1CDED27AE01E22EDB@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcO1z9qEP+1CL13GTzaRP1NQra+prgAAGmWg From: "Chris Boulton" To: "Ben Campbell" , "Paul Kyzivat" Cc: , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Nov 2003 16:55:51 -0000 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >-----Original=20Message----- >From:=20Ben=20Campbell=20[mailto:bcampbell@dynamicsoft.com] >Sent:=2010=20November=202003=2017:09 >To:=20Paul=20Kyzivat >Cc:=20hisham.khartabil@nokia.com;=20simple@ietf.org >Subject:=20Re:=20[Simple]=20Comments=20on=20message-sessions-02=20-=20mes= sage=20retry > >Paul=20Kyzivat=20wrote: > >[...] > >> >>=20I'm=20not=20certain=20a=20time=20period=20is=20really=20necessary.=20= I=20think=20this=20can be >>=20local=20option. >> >>=20Even=20uniqueness=20across=20streams=20isn't=20*required*,=20though=20= it=20would=20be >>=20helpful.=20Instead,=20we=20can=20simply=20introduce=20an=20error=20re= sponse=20to=20be used >>=20when=20a=20duplicate=20is=20detected=20and=20supressed.=20If=20it=20w= as=20supressed=20in error >>=20because=20the=20sender=20duplicated=20a=20TR-ID=20from=20another=20st= ream,=20the=20sender >>=20would=20then=20know=20to=20recover. >> >>=20But=20I=20agree=20that=20some=20further=20clarification=20on=20TR-ID=20= uniqueness=20could be >>=20helpful. >> > >If=20TR-ID=20is=20not=20required=20to=20be=20unique=20across=20sessions,=20= and=20you=20allow >clients=20to=20attempt=20to=20find=20duplicate=20messages=20using=20TR-ID= =20across >sessions,=20then=20you=20introduce=20the=20possibility=20of=20false=20det= ection=20caused >by=20TR-ID=20collisions.=20This=20seems=20bad=20to=20me. > [Chris=20Boulton]=20I=20totally=20agree. > > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Nov 28 12:08:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03941; Fri, 28 Nov 2003 12:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APm7C-0005Kx-00; Fri, 28 Nov 2003 12:09:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APm7C-0005Ku-00; Fri, 28 Nov 2003 12:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APm73-0006Hy-F4; Fri, 28 Nov 2003 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APm6G-0006Gr-N6 for simple@optimus.ietf.org; Fri, 28 Nov 2003 12:08:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03921 for ; Fri, 28 Nov 2003 12:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APm6F-0005Js-00 for simple@ietf.org; Fri, 28 Nov 2003 12:08:11 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1APm6E-0005JN-00 for simple@ietf.org; Fri, 28 Nov 2003 12:08:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hASH7Yd08029; Fri, 28 Nov 2003 11:07:34 -0600 Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions From: Robert Sparks To: Dirk.Trossen@nokia.com Cc: Ben Campbell , Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1070039253.935.37.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Nov 2003 11:07:33 -0600 Content-Transfer-Encoding: 7bit On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: > >-----Original Message----- > >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > >ext Robert Sparks > >Sent: Wednesday, November 26, 2003 1:36 AM > >To: Ben Campbell > >Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; > >simple@ietf.org > >Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions > > > > > >(speaking from the floor) > > > >In the presence/IM systems I've been using on a daily basis for > >some time now, I do not have a way to say "Allow everybody in > >foo.com except bar" and I still find these systems useful. > > > > Shall we conclude from this that current restrictions of systems is a useful measure to build future systems? You should conclude from this that there are environments in which being able to state exceptions is not a requirement. > > I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. I also believe exceptions would be useful. Very useful. I'm not arguing against supporting them. I am suggesting that it would be acceptable to have a base system that _didn't_ have them and an extension that does. > Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Nov 28 12:09:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03965 for ; Fri, 28 Nov 2003 12:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APm7E-0006K1-S6 for simple-archive@odin.ietf.org; Fri, 28 Nov 2003 12:09:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASH9CaT024295 for simple-archive@odin.ietf.org; Fri, 28 Nov 2003 12:09:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APm7E-0006Jm-OZ for simple-web-archive@optimus.ietf.org; Fri, 28 Nov 2003 12:09:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03941; Fri, 28 Nov 2003 12:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APm7C-0005Kx-00; Fri, 28 Nov 2003 12:09:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1APm7C-0005Ku-00; Fri, 28 Nov 2003 12:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APm73-0006Hy-F4; Fri, 28 Nov 2003 12:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APm6G-0006Gr-N6 for simple@optimus.ietf.org; Fri, 28 Nov 2003 12:08:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03921 for ; Fri, 28 Nov 2003 12:07:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APm6F-0005Js-00 for simple@ietf.org; Fri, 28 Nov 2003 12:08:11 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1APm6E-0005JN-00 for simple@ietf.org; Fri, 28 Nov 2003 12:08:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hASH7Yd08029; Fri, 28 Nov 2003 11:07:34 -0600 Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions From: Robert Sparks To: Dirk.Trossen@nokia.com Cc: Ben Campbell , Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1070039253.935.37.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 28 Nov 2003 11:07:33 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: > >-----Original Message----- > >From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > >ext Robert Sparks > >Sent: Wednesday, November 26, 2003 1:36 AM > >To: Ben Campbell > >Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; > >simple@ietf.org > >Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions > > > > > >(speaking from the floor) > > > >In the presence/IM systems I've been using on a daily basis for > >some time now, I do not have a way to say "Allow everybody in > >foo.com except bar" and I still find these systems useful. > > > > Shall we conclude from this that current restrictions of systems is a useful measure to build future systems? You should conclude from this that there are environments in which being able to state exceptions is not a requirement. > > I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. I also believe exceptions would be useful. Very useful. I'm not arguing against supporting them. I am suggesting that it would be acceptable to have a base system that _didn't_ have them and an extension that does. > Dirk _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple