From mailnull@www1.ietf.org Thu May 1 04:54:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02664 for ; Thu, 1 May 2003 04:54:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h418xbt04142 for simple-archive@odin.ietf.org; Thu, 1 May 2003 04:59:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418xb804139 for ; Thu, 1 May 2003 04:59:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02643 for ; Thu, 1 May 2003 04:53:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9qb-0007Tp-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 04:55:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B9qa-0007Tg-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 04:55:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418xQ804116; Thu, 1 May 2003 04:59:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418rt803743 for ; Thu, 1 May 2003 04:53:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02489 for ; Thu, 1 May 2003 04:47:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9l5-0007Px-00 for simple@ietf.org; Thu, 01 May 2003 04:49:39 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B9kz-0007Pd-00 for simple@ietf.org; Thu, 01 May 2003 04:49:33 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h418n7dh004834; Thu, 1 May 2003 04:49:08 -0400 (EDT) Message-ID: <3EB0DF80.3010503@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Implications of removing connection sharing References: <1051734948.1500.102.camel@verite.localdomain> In-Reply-To: <1051734948.1500.102.camel@verite.localdomain> 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, 01 May 2003 04:49:04 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > We seem to have a consensus to remove connection sharing from the spec, > at least for TCP connections. I think we have not yet converged on > whether SCTP offers a solution for multiplexing multiple sessions over > the same connection between relays or not. > > Ignoring the SCTP discussions for the moment, removing connection > sharing has a few implications. These are probably good implications, > where good is defined as simplifying the protocol. But they may suggest > some fundemental changes to the way MSRP works. > > 1) Without connection sharing, it becomes easier to treat relays as > connection tunneling devices rather than message switchers. Several > people have suggested a desire to do this or something similar. I use an > HTTPS proxy as an example, where once the session is established across > the proxy, the proxy just forwards packets back and forth. This has some > nice properties. You can have e2e TLS handshakes in spite of the > existance of relays. This is a bit more complicated than in the HTTP case. Thats because you will have two user agents, both of which could be clients for TCP (that is, both open TCP connections to a relay), but one of which will act as a server for the TLS handshake. The normal HTTPS case is that the TCP client is also the TLS client, and the TCP server is the TLS server. We would first need to figure out who acts as the TLS client (not hard), but my concern is that TLS libraries wouldn't support this mode. Furthermore, since clients are not going to have certs, I don't see this being useful. I also recall discussing this model of just doing byte switching based on tcp connections a long time back. One of the concerns raised was that people wanted these relays to do logging of messages, and this wouldn't work in a relay that is not message oriented. In fact, I recall having a requirement to this effect in my original email on requirements. A slightly different model is that the stream switching is limited to the case where a user basically does a visit through a relay. In other words, in the two relay case, if user A does a BIND to its relay, that relay becomes the termination point of a TLS connection. When the other client does a visit, is TLS connection is tunneled through its relay, but terminates on the one where the BIND took place. This has the benefit of making the TLS usage resemble the web model. It doesn't help the logging problem since the relay on the visiting side still won't see messages. I dont recall if there were other problems with this byte-switching approach beyond the logging. You can simplify flow control--if a relay is > blocked sending on a downstream connection, it just stops receiving on > an upstream connection. If a downstream connection drops, the relay can > just drop the upstream connection and let the prior hop deal with it at > the transport level. You don't need this byte-switching approach to achieve that. You can get it with message oriented too. > > 2) Their is no longer a need for a MSRP to contain headers to identify > the session it belongs to. The session is fully determined by the > connection on which it arrives. This is interesting because it seems to > make generalization of MSRP sessions to allow more than two participants > an easy extension. If more than 2 connections are associated with a > session, you simply send data received for a session to all connections > except the one it arrived on. Actually, it occurs to me that if we go for this kind of byte-forwarding approach, MSRP basically turns into TURN plus some message framing. That is, we would more or less be back to designing a protocol for the no-relay case, and to deal with fw/nat, be using something like TURN. Its not quite TURN since TURN doesn't have this notion of the HTTP CONNECT type of tactic, though I must admit I have been considering adding that to TURN, in which case it would be exactly equivalent. TURN was one of the proposals on the table for dealing with relays for message sessions way back when... feels like we are going in circles :( -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Thu May 1 04:54:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02679 for ; Thu, 1 May 2003 04:54:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4190BP04287 for simple-archive@odin.ietf.org; Thu, 1 May 2003 05:00:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4190B804284 for ; Thu, 1 May 2003 05:00:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02660 for ; Thu, 1 May 2003 04:53:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9r9-0007Tz-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 04:55:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B9r8-0007Tv-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 04:55:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41903804233; Thu, 1 May 2003 05:00:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h418vA804009 for ; Thu, 1 May 2003 04:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02586 for ; Thu, 1 May 2003 04:50:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9oE-0007SN-00 for simple@ietf.org; Thu, 01 May 2003 04:52:54 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19B9o8-0007S3-00 for simple@ietf.org; Thu, 01 May 2003 04:52:48 -0400 Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h418qSdh004837; Thu, 1 May 2003 04:52:29 -0400 (EDT) Message-ID: <3EB0E048.8070704@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Adam Roach , Ben Campbell , Simple WG Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) References: <9BF66EBF6BEFD942915B4D4D45C051F3A64751@dyn-tx-exch-001.dynamicsoft.com> <3EB03FA7.8010503@cisco.com> In-Reply-To: <3EB03FA7.8010503@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, 01 May 2003 04:52:24 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Adam Roach wrote: > >> Ben Campbell writes: >> >> >>> Jonathan suggested we should handle flow control by simply dropping >>> messages. This is not as heinous as it first sounds, since MSRP does >>> have e2e acknowledgement of message delivery. >> >> >> >> The prospect of designing yet another protocol that needs to >> retransmit requests over a *reliable* transport layer if >> no response is received makes me more than a little queasy. > > > You beat me to it - my stomach has been bothering me for awhile too. > > I'm trying to remember why we put the end-to-end acks in. I'm quite sure > it wasn't so we could drop messages with the expectation that the sender > would retry them. I think maybe it was so the sender can detect when the > other end fails. Acknowledgement of message receipt is a basic requirement from rfc2779. I also recall it was to deal with failures at relays too. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Thu May 1 08:07:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06322 for ; Thu, 1 May 2003 08:07:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41CDwU15777 for simple-archive@odin.ietf.org; Thu, 1 May 2003 08:13:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41CDw815774 for ; Thu, 1 May 2003 08:13:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06317 for ; Thu, 1 May 2003 08:07:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BCsb-0000TU-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 08:09:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BCsb-0000TR-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 08:09:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41CDm815765; Thu, 1 May 2003 08:13:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41C8i815613 for ; Thu, 1 May 2003 08:08:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06242 for ; Thu, 1 May 2003 08:02:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BCnX-0000Ry-00 for simple@ietf.org; Thu, 01 May 2003 08:04:24 -0400 Received: from d12lmsgate.de.ibm.com ([194.196.100.234]) by ietf-mx with esmtp (Exim 4.12) id 19BCnS-0000RO-00 for simple@ietf.org; Thu, 01 May 2003 08:04:18 -0400 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h41C3gu9049162 for ; Thu, 1 May 2003 14:03:42 +0200 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h41C3gqu187922 for ; Thu, 1 May 2003 14:03:42 +0200 To: Simple WG MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 01/05/2003 15:03:42, Serialize complete at 01/05/2003 15:03:42 Content-Type: text/plain; charset="US-ASCII" Subject: [Simple] SIMPLE arch document Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 1 May 2003 15:03:39 +0300 The SIMPLE charter specifies the following deliverable: "An architecture for the implementation of a traditional buddylist- based instant messaging and presence application with SIP, including for example new mechanisms for message confirmation delivery, indications for when a party is in the process of typing a message, secure buddylist manipulation operations, and the extension of the CPIM presence format to describe typical IM states." We have submitted a (very) initial skeleton document for the above: http://www.ietf.org/internet-drafts/draft-houri-simple-arch-00.txt I know that the document tries to cover much more then what was intended. However, in order to continue working on the document we would like to get some feedback from the group. Any input will be appreciated. Thanks Avshalom _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 09:02:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07658 for ; Thu, 1 May 2003 09:02:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41D8Fa21920 for simple-archive@odin.ietf.org; Thu, 1 May 2003 09:08:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D8F821915 for ; Thu, 1 May 2003 09:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07629 for ; Thu, 1 May 2003 09:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDj7-0000lm-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:03:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BDj7-0000li-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:03:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D87821906; Thu, 1 May 2003 09:08:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D7h821846 for ; Thu, 1 May 2003 09:07:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07614 for ; Thu, 1 May 2003 09:01:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDib-0000lQ-00 for simple@ietf.org; Thu, 01 May 2003 09:03:21 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19BDiQ-0000lH-00 for simple@ietf.org; Thu, 01 May 2003 09:03:10 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h41D3VKN002227 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 1 May 2003 09:03:31 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h41D3UcE016860; Thu, 1 May 2003 09:03:30 -0400 (EDT) Message-ID: <3EB11B07.4030200@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , Adam Roach , Ben Campbell , Simple WG Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) References: <9BF66EBF6BEFD942915B4D4D45C051F3A64751@dyn-tx-exch-001.dynamicsoft.com> <3EB03FA7.8010503@cisco.com> <3EB0E048.8070704@dynamicsoft.com> In-Reply-To: <3EB0E048.8070704@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, 01 May 2003 09:03:03 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Acknowledgement of message receipt is a basic requirement from rfc2779. > > I also recall it was to deal with failures at relays too. There is, however, a difference in degree between rare failures induced by relays crashing and congestion/flow control dropping, which would occur at a much higher rate if there's a heterogeneous chain. Plus, using dropping to regulate flows is a dicey mechanism, since you can easily get into congestion collapse, spending all your time and network resources on dropping things. Thus, you have to have a back-off mechanism, RTO estimation, slow start - and, congratulations, you have re-invented TCP at the MSRP layer. Thus, I'm all for delivery confirmation, but in the spirit of email delivery confirmation, not TCP. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 09:21:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08532 for ; Thu, 1 May 2003 09:21:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41DRK126122 for simple-archive@odin.ietf.org; Thu, 1 May 2003 09:27:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DRK826119 for ; Thu, 1 May 2003 09:27:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08511 for ; Thu, 1 May 2003 09:20:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BE1a-00011P-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:22:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BE1Z-00011J-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:22:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DRA826082; Thu, 1 May 2003 09:27:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DPv825856 for ; Thu, 1 May 2003 09:25:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08478 for ; Thu, 1 May 2003 09:19:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BE0E-00010X-00 for simple@ietf.org; Thu, 01 May 2003 09:21:35 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19BE09-0000yK-00 for simple@ietf.org; Thu, 01 May 2003 09:21:29 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h41DIV4c025874; Thu, 1 May 2003 09:18:31 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABI27721; Thu, 1 May 2003 09:27:20 -0400 (EDT) Message-ID: <3EB11EA5.90103@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: "Peterson, Jon" CC: "'Henning Schulzrinne'" , Ben Campbell , "David R. Oran" , Robert Sparks , Adam Roach , Cullen Jennings , Simple WG Subject: Re: [Simple] Re: MSRP Requirements References: <0449D80A0E9B614A83FA9031B07E8D3B257A1A@stntexch2.va.neustar.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, 01 May 2003 09:18:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jon, Its great that there actually are requirements. I've no interest in doing that work over if it is done. However we may want to consider how appropriate and adequate those seem in the light of what we have learned since. (That's assuming we have learned anything - its not entirely clear we have.) One thing I noticed in the im session guide is that there is discussion of connection sharing, with figure 3 showing IM Muxers and an aggregate circuit. But none of that is reflected in the normative guidelines. I presume that was intentional? Paul Peterson, Jon wrote: > I suspected this draft might come in handy someday. I am hesitant at this > point in our process to start drafting new frameworks and requirements for > message sessions. The im-session-guide draft was intended to provide a > framework and requirements (the latter especially in section 5) for > precisely this space: it has the necessary transport slant, and a good deal > of UNSAF/OPES-like warnings. > > Here's the HTML version of the draft: > > http://unreason.com/jfp/ietf/draft-mankin-im-session-guide-00.html > > I'd be happy to resurrect this draft, anyway, if it would be useful. > > Jon Peterson > NeuStar, Inc. > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Wednesday, April 30, 2003 6:41 AM >>To: Ben Campbell >>Cc: Paul Kyzivat; David R. Oran; Robert Sparks; Adam Roach; Cullen >>Jennings; Simple WG >>Subject: Re: [Simple] Re: MSRP Requirements >> >> >>Like most SIP drafts... >> >>http://www.cs.columbia.edu/sip/drafts/draft-mankin-im-session- >>guide-00.txt >> >>Ben Campbell wrote: >> >> >>>Mary Barnes (Thanks Mary!!) was kind enough to dig up the >> >>original email >> >>>(from 2001!) where Jonathan proposed some message session >> >>requirements. >> >>>I notice that Paul's thread covers most of this, with the possible >>>exception of the "lightweight" requirement. >>> >>>Additionally, she reminded me that Allison and Jon put out >>>draft-mankin-im-session-guide-00.txt as a discussion of >> >>transport issues >> >>>for IM sessions. That draft seems to have expired and >> >>fallen out of the >> >>>repository. Anyone have a copy? (Jon?) >> >> >>_______________________________________________ >>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 mailnull@www1.ietf.org Thu May 1 09:22:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08585 for ; Thu, 1 May 2003 09:22:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41DSAB26175 for simple-archive@odin.ietf.org; Thu, 1 May 2003 09:28:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DSA826172 for ; Thu, 1 May 2003 09:28:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08552 for ; Thu, 1 May 2003 09:21:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BE2O-000128-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:23:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BE2N-000122-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:23:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DS1826159; Thu, 1 May 2003 09:28:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DRw826144 for ; Thu, 1 May 2003 09:27:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08547 for ; Thu, 1 May 2003 09:21:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BE2B-00011v-00 for simple@ietf.org; Thu, 01 May 2003 09:23:35 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19BE25-00010M-00 for simple@ietf.org; Thu, 01 May 2003 09:23:29 -0400 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.6/8.12.6) with ESMTP id h41DLqua024114; Thu, 1 May 2003 06:21:52 -0700 (PDT) Received: from [142.131.37.60] (sjc-vpn1-448.cisco.com [10.21.97.192]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADS96202; Thu, 1 May 2003 06:21:50 -0700 (PDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: [Simple] MSRP: Implications of removing connection sharing From: Cullen Jennings To: Ben Campbell , Simple WG Message-ID: In-Reply-To: <1051734948.1500.102.camel@verite.localdomain> 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, 30 Apr 2003 20:08:58 -0700 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My goal in the original posting was to get some discussion on topic because I felt it was needed - I certainly can't complain about the lack of discussion. I'm ok with a SHOULD for SCTP between relays and I do understand what Henning pointed out - I'm fairly doubtful SCTP would be implemented but it's worth a try. Designing our own mux scheme that works seems both hard and a bad idea. I notice there has not been much discussion on the BEEP possibility. A few of my own back of the envelope calculation indicate that two separate TLS connection for every session at every relay might scale OK but I don't see how we can decide this with absolutely no statements or assumptions about the scale of the systems we are trying to design a solution for. I suspect there are a few more people that have been watching the conversation are going to think about all of it and, when they get a chance, post a few opinions. Given the lack of a concrete proposal, of what the requirements are or how to solve them, I'd think it's a bit early to claim consensus on this topic yet. I agree we need to move quick on this. Cullen PS. I notice the argument on this topic has taken a very strange form: It now looks something like - We have proved that X will not work. So we are treating that as consensus to go do (not X) with little discussion of if (not X) will work or not. On 4/30/03 1:35 PM, "Ben Campbell" wrote: > We seem to have a consensus to remove connection sharing from the spec, > at least for TCP connections. I think we have not yet converged on > whether SCTP offers a solution for multiplexing multiple sessions over > the same connection between relays or not. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 09:37:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09416 for ; Thu, 1 May 2003 09:37:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Dhdl31254 for simple-archive@odin.ietf.org; Thu, 1 May 2003 09:43:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Dhd831251 for ; Thu, 1 May 2003 09:43:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09395 for ; Thu, 1 May 2003 09:37:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEHM-0001FO-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:39:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BEHM-0001FL-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:39:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DhN831232; Thu, 1 May 2003 09:43:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41DeR830053 for ; Thu, 1 May 2003 09:40:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09160 for ; Thu, 1 May 2003 09:33:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEEG-0001Bm-00 for simple@ietf.org; Thu, 01 May 2003 09:36:04 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19BEEB-0001BX-00 for simple@ietf.org; Thu, 01 May 2003 09:35:59 -0400 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 h41DZL916594; Thu, 1 May 2003 08:35:21 -0500 Subject: Re: [Simple] Re: MSRP Requirements From: Ben Campbell To: Paul Kyzivat Cc: Jon Peterson , "'Henning Schulzrinne'" , "David R. Oran" , Robert Sparks , Adam Roach , Cullen Jennings , Simple WG In-Reply-To: <3EB11EA5.90103@cisco.com> References: <0449D80A0E9B614A83FA9031B07E8D3B257A1A@stntexch2.va.neustar.com> <3EB11EA5.90103@cisco.com> Content-Type: text/plain Message-Id: <1051795832.3680.26.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 01 May 2003 08:30:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-05-01 at 08:18, Paul Kyzivat wrote: > Jon, > > Its great that there actually are requirements. I've no interest in > doing that work over if it is done. However we may want to consider how > appropriate and adequate those seem in the light of what we have learned > since. (That's assuming we have learned anything - its not entirely > clear we have.) > > One thing I noticed in the im session guide is that there is discussion > of connection sharing, with figure 3 showing IM Muxers and an aggregate > circuit. But none of that is reflected in the normative guidelines. I > presume that was intentional? > I interpreted that to mean that, if their is session aggregation, certain requirements are implied. But aggregation is not a requirement in itself. > Paul > > Peterson, Jon wrote: > > I suspected this draft might come in handy someday. I am hesitant at this > > point in our process to start drafting new frameworks and requirements for > > message sessions. The im-session-guide draft was intended to provide a > > framework and requirements (the latter especially in section 5) for > > precisely this space: it has the necessary transport slant, and a good deal > > of UNSAF/OPES-like warnings. > > > > Here's the HTML version of the draft: > > > > http://unreason.com/jfp/ietf/draft-mankin-im-session-guide-00.html > > > > I'd be happy to resurrect this draft, anyway, if it would be useful. > > > > Jon Peterson > > NeuStar, Inc. > > > > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Wednesday, April 30, 2003 6:41 AM > >>To: Ben Campbell > >>Cc: Paul Kyzivat; David R. Oran; Robert Sparks; Adam Roach; Cullen > >>Jennings; Simple WG > >>Subject: Re: [Simple] Re: MSRP Requirements > >> > >> > >>Like most SIP drafts... > >> > >>http://www.cs.columbia.edu/sip/drafts/draft-mankin-im-session- > >>guide-00.txt > >> > >>Ben Campbell wrote: > >> > >> > >>>Mary Barnes (Thanks Mary!!) was kind enough to dig up the > >> > >>original email > >> > >>>(from 2001!) where Jonathan proposed some message session > >> > >>requirements. > >> > >>>I notice that Paul's thread covers most of this, with the possible > >>>exception of the "lightweight" requirement. > >>> > >>>Additionally, she reminded me that Allison and Jon put out > >>>draft-mankin-im-session-guide-00.txt as a discussion of > >> > >>transport issues > >> > >>>for IM sessions. That draft seems to have expired and > >> > >>fallen out of the > >> > >>>repository. Anyone have a copy? (Jon?) > >> > >> > >>_______________________________________________ > >>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 mailnull@www1.ietf.org Thu May 1 09:49:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07659 for ; Thu, 1 May 2003 09:02:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41D8FS21934 for simple-archive@odin.ietf.org; Thu, 1 May 2003 09:08:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D8F821917 for ; Thu, 1 May 2003 09:08:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07630 for ; Thu, 1 May 2003 09:01:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDj7-0000lp-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:03:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BDj7-0000lj-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 09:03:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D85821887; Thu, 1 May 2003 09:08:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41D7b821736 for ; Thu, 1 May 2003 09:07:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07610 for ; Thu, 1 May 2003 09:01:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BDiV-0000lK-00 for simple@ietf.org; Thu, 01 May 2003 09:03:15 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19BDiK-0000hL-00 for simple@ietf.org; Thu, 01 May 2003 09:03:04 -0400 Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h41CxUKN002077 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 1 May 2003 08:59:31 -0400 (EDT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h41CxTcE016848; Thu, 1 May 2003 08:59:29 -0400 (EDT) Message-ID: <3EB11A15.70906@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Ben Campbell , Simple WG Subject: Re: [Simple] MSRP: Implications of removing connection sharing References: <1051734948.1500.102.camel@verite.localdomain> <3EB0DF80.3010503@dynamicsoft.com> In-Reply-To: <3EB0DF80.3010503@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, 01 May 2003 08:59:01 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I also recall discussing this model of just doing byte switching based > on tcp connections a long time back. One of the concerns raised was that > people wanted these relays to do logging of messages, and this wouldn't > work in a relay that is not message oriented. In fact, I recall having a > requirement to this effect in my original email on requirements. I don't see why byte-streaming interferes with logging. This is just while not end-of-message { read block from input socket if (header) { stick in header buffer if header done parse header set up logging information dump header into output socket } else { write block to output socket write block to logging device (socket, file, ...) } } _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 10:00:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10597 for ; Thu, 1 May 2003 10:00:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41E6Jj02921 for simple-archive@odin.ietf.org; Thu, 1 May 2003 10:06:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41E6J802918 for ; Thu, 1 May 2003 10:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10550 for ; Thu, 1 May 2003 09:59:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEdI-0001XB-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 10:01:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BEdH-0001X6-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 10:01:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41E68802781; Thu, 1 May 2003 10:06:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41E08801101 for ; Thu, 1 May 2003 10:00:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10122 for ; Thu, 1 May 2003 09:53:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BEXJ-0001RI-00 for simple@ietf.org; Thu, 01 May 2003 09:55:45 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19BEXE-0001QX-00 for simple@ietf.org; Thu, 01 May 2003 09:55:40 -0400 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 h41DtJ916877; Thu, 1 May 2003 08:55:19 -0500 Subject: Re: [Simple] MSRP: Implications of removing connection sharing From: Ben Campbell To: Jonathan Rosenberg Cc: Simple WG In-Reply-To: <3EB0DF80.3010503@dynamicsoft.com> References: <1051734948.1500.102.camel@verite.localdomain> <3EB0DF80.3010503@dynamicsoft.com> Content-Type: text/plain Message-Id: <1051797005.3680.44.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 01 May 2003 08:50:05 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-05-01 at 03:49, Jonathan Rosenberg wrote: > inline. > > Ben Campbell wrote: > > We seem to have a consensus to remove connection sharing from the spec, > > at least for TCP connections. I think we have not yet converged on > > whether SCTP offers a solution for multiplexing multiple sessions over > > the same connection between relays or not. > > > > Ignoring the SCTP discussions for the moment, removing connection > > sharing has a few implications. These are probably good implications, > > where good is defined as simplifying the protocol. But they may suggest > > some fundemental changes to the way MSRP works. > > > > 1) Without connection sharing, it becomes easier to treat relays as > > connection tunneling devices rather than message switchers. Several > > people have suggested a desire to do this or something similar. I use an > > HTTPS proxy as an example, where once the session is established across > > the proxy, the proxy just forwards packets back and forth. This has some > > nice properties. You can have e2e TLS handshakes in spite of the > > existance of relays. > > This is a bit more complicated than in the HTTP case. Thats because you > will have two user agents, both of which could be clients for TCP (that > is, both open TCP connections to a relay), but one of which will act as > a server for the TLS handshake. The normal HTTPS case is that the TCP > client is also the TLS client, and the TCP server is the TLS server. We > would first need to figure out who acts as the TLS client (not hard), > but my concern is that TLS libraries wouldn't support this mode. In both cases, you would build an e2e "virtual" connection, then execute a starttls. While I have not _proven_ this is supported by common TLS libraries, but I would be surprised if it was not. I agree, we would have to add some complexity to determine who is the server. > > Furthermore, since clients are not going to have certs, I don't see this > being useful. Do we have a requirement to support e2e protection for clients with no certs? I have to point out that almost _any_ security scheme we have discussed eventually requires client certs. For example, assume we use s/mime with session keys negotiated in the sdp. We would then have to protect the _sdp_ exchange with s/mime, which would require s/mime certs at the clients. > > I also recall discussing this model of just doing byte switching based > on tcp connections a long time back. One of the concerns raised was that > people wanted these relays to do logging of messages, and this wouldn't > work in a relay that is not message oriented. In fact, I recall having a > requirement to this effect in my original email on requirements. You _could_ just log the byte-stream, then parse out messages after the fact. (This of course interacts with any encryption scheme, but I think that is ok.) > > A slightly different model is that the stream switching is limited to > the case where a user basically does a visit through a relay. In other > words, in the two relay case, if user A does a BIND to its relay, that > relay becomes the termination point of a TLS connection. When the other > client does a visit, is TLS connection is tunneled through its relay, > but terminates on the one where the BIND took place. > > This has the benefit of making the TLS usage resemble the web model. It > doesn't help the logging problem since the relay on the visiting side > still won't see messages. > > I dont recall if there were other problems with this byte-switching > approach beyond the logging. I believe that the _biggest_ reason was the connection sharing issue. > > You can simplify flow control--if a relay is > > blocked sending on a downstream connection, it just stops receiving on > > an upstream connection. If a downstream connection drops, the relay can > > just drop the upstream connection and let the prior hop deal with it at > > the transport level. > > You don't need this byte-switching approach to achieve that. You can get > it with message oriented too. But you get better granularity with byte or chunk switching. If you don't start sending a message downstream until you fully receive it from upstream, you end up having to buffer a lot more if you have large messages. > > > > > 2) Their is no longer a need for a MSRP to contain headers to identify > > the session it belongs to. The session is fully determined by the > > connection on which it arrives. This is interesting because it seems to > > make generalization of MSRP sessions to allow more than two participants > > an easy extension. If more than 2 connections are associated with a > > session, you simply send data received for a session to all connections > > except the one it arrived on. > > Actually, it occurs to me that if we go for this kind of byte-forwarding > approach, MSRP basically turns into TURN plus some message framing. That > is, we would more or less be back to designing a protocol for the > no-relay case, and to deal with fw/nat, be using something like TURN. > Its not quite TURN since TURN doesn't have this notion of the HTTP > CONNECT type of tactic, though I must admit I have been considering > adding that to TURN, in which case it would be exactly equivalent. > > TURN was one of the proposals on the table for dealing with relays for > message sessions way back when... feels like we are going in circles :( Hopefully, we have enough participants in this dicussion that we can end the circle now. > > -Jonathan R. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 11:15:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16351 for ; Thu, 1 May 2003 11:15:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FLLY22649 for simple-archive@odin.ietf.org; Thu, 1 May 2003 11:21:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FLL822642 for ; Thu, 1 May 2003 11:21:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16271 for ; Thu, 1 May 2003 11:14:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFnt-0002cU-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:16:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BFns-0002c2-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:16:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FLB822334; Thu, 1 May 2003 11:21:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FCJ819939 for ; Thu, 1 May 2003 11:12:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15734 for ; Thu, 1 May 2003 11:05:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFf9-0002T7-00 for simple@ietf.org; Thu, 01 May 2003 11:07:55 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFf3-0002Sg-00 for simple@ietf.org; Thu, 01 May 2003 11:07:49 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41F7fWU011515; Thu, 1 May 2003 11:07:43 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACG23656; Thu, 1 May 2003 11:07:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501105724.00b807b8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Adam Roach From: Michael Hammer Subject: RE: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) Cc: "'Dean Willis'" , Adam Roach , "'Simple WG'" In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3A64750@dyn-tx-exch-001.dyn amicsoft.com> Mime-Version: 1.0 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: Thu, 01 May 2003 11:07:37 -0400 At 02:12 PM 4/30/2003 -0500, Adam Roach wrote: >The situation that we've been calling head of line >blocking in this thread isn't that. It's a "shared >input queue with multiple output queues where filling >up one output queue must not cause the other output >queues to block" problem. ("siqwmoqwfuooqmnctooqtb", >for short -- which is why, I guess, we've hijacked >the term "head-of-line blocking"). It would appear that pushing the problem to a higher layer doesn't solve the problem, just makes it an application layer problem instead of a transport layer problem. The problem here seems to be that a particular flow is allowed to hog resources at three possible points (input link, relay buffers, output link) and cause a stoppage. My question is why the implementation would allow that to occur? If it were managing resources well, it should be multiplexing the link resources on both inputs and outputs so that one stream doesn't slow everything else down. Is it not possible to recognize this and open additional transport connections, while reducing the window or reducing credit to the offending stream? My feeling is that this is a transport layer problem and should be addressed at that level, rather than in an application layer protocol. Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 11:15:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16365 for ; Thu, 1 May 2003 11:15:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FLPR22761 for simple-archive@odin.ietf.org; Thu, 1 May 2003 11:21:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FLP822758 for ; Thu, 1 May 2003 11:21:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16279 for ; Thu, 1 May 2003 11:14:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFnx-0002cc-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:17:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BFnw-0002cP-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:17:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FLE822449; Thu, 1 May 2003 11:21:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FER820042 for ; Thu, 1 May 2003 11:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15797 for ; Thu, 1 May 2003 11:07:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFhD-0002UC-00 for simple@ietf.org; Thu, 01 May 2003 11:10:03 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BFh7-0002Tx-00 for simple@ietf.org; Thu, 01 May 2003 11:09:57 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41F9oWS012259; Thu, 1 May 2003 11:09:50 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACG23696; Thu, 1 May 2003 11:09:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501110855.00b97d40@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ben Campbell From: Michael Hammer Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards closure on HoL blocking issue) Cc: "David R. Oran" , Robert Sparks , Adam Roach , Jonathan Rosenberg , Paul Kyzivat , Cullen Jennings , Simple WG In-Reply-To: <1051631885.1568.24.camel@dhcp31.dfw.dynamicsoft.com> References: <418788115.1051614834@ORANLT.dhcp110.enet.interop.net> <1051557511.2721.28.camel@verite.localdomain> <418788115.1051614834@ORANLT.dhcp110.enet.interop.net> Mime-Version: 1.0 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: Thu, 01 May 2003 11:09:48 -0400 Ben, Does it matter whether the "clients" are single-user versus multi-user? I'm wondering where the first point of multiplexing is. Mike At 10:58 AM 4/29/2003 -0500, Ben Campbell wrote: >OK, we now have several people coming out to say that they think sharing >connections across multiple MSRP sessions should not be a requirement. >But we previously had pretty strong support for it. Since this concept >is the motivation for a number of other MSRP decisions that are proving >controversial, I suggest we make a decision on it now. > > > >So, please respond to the following questions: > >1) Do we really need connection sharing between clients and relays? > >2) Do we really need connection sharing between relays? > > >On Tue, 2003-04-29 at 10:13, David R. Oran wrote: > > Sorry if I'm jumping in late. I much prefer to KISS and do nothing, as > > proposed by Henning. If we want to multilex transport connections in the > > future for relays, do it with SCTP and have one stream per client session. > > > > Dave. > > > > > > --On Monday, April 28, 2003 2:18 PM -0500 Ben Campbell > > wrote: > > > > > We have had lots of discussion on this, going off in several directions. > > > > > > I re-propose the following. If anyone has serious objections, please > > > speak up. (Actually, I would appreciate it if anyone who has previously > > > expressed an opinion on this matter to speak up one way or another.) > > > > > > 1. 64k-1 end-to-end size limit on MSRP requests, enforced by a fixed > > > length message size field. > > > > > > 2. Chunking pushed to a future (but real soon) work. Chunking would be > > > endpoint controlled, negotiated in SDP, and likely based on the existing > > > MIME message/partial spec with some relaxation of the 7 bit rules, etc., > > > that Adam mentioned. > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > ------------------------ > > David R. Oran > > Cisco Systems > > 7 Ladyslipper Lane > > Acton, MA 01720 > > Office: +1 978 264 2048 > > VoIP: +1 408 571 4576 > > Email: oran@cisco.com > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 11:22:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16713 for ; Thu, 1 May 2003 11:22:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FSCZ24121 for simple-archive@odin.ietf.org; Thu, 1 May 2003 11:28:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FSC824118 for ; Thu, 1 May 2003 11:28:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16695 for ; Thu, 1 May 2003 11:21:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFuV-0002jX-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:23:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BFuV-0002jP-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:23:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FS2824068; Thu, 1 May 2003 11:28:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FRU823635 for ; Thu, 1 May 2003 11:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16610 for ; Thu, 1 May 2003 11:20:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BFtp-0002hX-00 for simple@ietf.org; Thu, 01 May 2003 11:23:06 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19BFtk-0002gF-00 for simple@ietf.org; Thu, 01 May 2003 11:23:00 -0400 Received: from localhost (root@localhost [127.0.0.1]) by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h41FM3Fr013896; Thu, 1 May 2003 10:22:04 -0500 (CDT) Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards closure on HoL blocking issue) From: Ben Campbell To: Michael Hammer Cc: "David R. Oran" , Robert Sparks , Adam Roach , Jonathan Rosenberg , Paul Kyzivat , Cullen Jennings , Simple WG In-Reply-To: <4.3.2.7.2.20030501110855.00b97d40@cia.cisco.com> References: <418788115.1051614834@ORANLT.dhcp110.enet.interop.net> <1051557511.2721.28.camel@verite.localdomain> <418788115.1051614834@ORANLT.dhcp110.enet.interop.net> <4.3.2.7.2.20030501110855.00b97d40@cia.cisco.com> Content-Type: text/plain Message-Id: <1051802472.1543.2.camel@dhcp31.dfw.dynamicsoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 01 May 2003 10:21:12 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The existing draft assumes connection sharing is possible at client-client, client-relay, and relay-relay connections. So for a multiuser client, the first point of multiplexing could be the client itself. If we do away with sharing at client-client and client-relay, then, at least over TCP, a multi-user client would need to open a separate connection for each session. On Thu, 2003-05-01 at 10:09, Michael Hammer wrote: > Ben, > > Does it matter whether the "clients" are single-user versus multi-user? > > I'm wondering where the first point of multiplexing is. > > Mike > > At 10:58 AM 4/29/2003 -0500, Ben Campbell wrote: > >OK, we now have several people coming out to say that they think sharing > >connections across multiple MSRP sessions should not be a requirement. > >But we previously had pretty strong support for it. Since this concept > >is the motivation for a number of other MSRP decisions that are proving > >controversial, I suggest we make a decision on it now. > > > > > > > >So, please respond to the following questions: > > > >1) Do we really need connection sharing between clients and relays? > > > >2) Do we really need connection sharing between relays? > > > > > >On Tue, 2003-04-29 at 10:13, David R. Oran wrote: > > > Sorry if I'm jumping in late. I much prefer to KISS and do nothing, as > > > proposed by Henning. If we want to multilex transport connections in the > > > future for relays, do it with SCTP and have one stream per client session. > > > > > > Dave. > > > > > > > > > --On Monday, April 28, 2003 2:18 PM -0500 Ben Campbell > > > wrote: > > > > > > > We have had lots of discussion on this, going off in several directions. > > > > > > > > I re-propose the following. If anyone has serious objections, please > > > > speak up. (Actually, I would appreciate it if anyone who has previously > > > > expressed an opinion on this matter to speak up one way or another.) > > > > > > > > 1. 64k-1 end-to-end size limit on MSRP requests, enforced by a fixed > > > > length message size field. > > > > > > > > 2. Chunking pushed to a future (but real soon) work. Chunking would be > > > > endpoint controlled, negotiated in SDP, and likely based on the existing > > > > MIME message/partial spec with some relaxation of the 7 bit rules, etc., > > > > that Adam mentioned. > > > > > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > > > > ------------------------ > > > David R. Oran > > > Cisco Systems > > > 7 Ladyslipper Lane > > > Acton, MA 01720 > > > Office: +1 978 264 2048 > > > VoIP: +1 408 571 4576 > > > Email: oran@cisco.com > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 11:41:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17974 for ; Thu, 1 May 2003 11:41:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FlJK29756 for simple-archive@odin.ietf.org; Thu, 1 May 2003 11:47:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FlJ829753 for ; Thu, 1 May 2003 11:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17937 for ; Thu, 1 May 2003 11:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGD0-0002yP-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:42:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGCz-0002yE-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:42:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fl8829660; Thu, 1 May 2003 11:47:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FkU828968 for ; Thu, 1 May 2003 11:46:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17837 for ; Thu, 1 May 2003 11:39:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGCD-0002wO-00 for simple@ietf.org; Thu, 01 May 2003 11:42:05 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19BGC7-0002wG-00 for simple@ietf.org; Thu, 01 May 2003 11:41:59 -0400 Received: from localhost (root@localhost [127.0.0.1]) by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h41FflFr015803; Thu, 1 May 2003 10:41:48 -0500 (CDT) Subject: Re: [Simple] MSRP: Implications of removing connection sharing From: Ben Campbell To: Cullen Jennings Cc: Simple WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1051803631.1524.20.camel@dhcp31.dfw.dynamicsoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 01 May 2003 10:40:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wed, 2003-04-30 at 22:08, Cullen Jennings wrote: [...] > PS. I notice the argument on this topic has taken a very strange form: It > now looks something like - We have proved that X will not work. So we are > treating that as consensus to go do (not X) with little discussion of if > (not X) will work or not. > Hmm. I was interpreting two parts to the argument: 1) The feature of session multiplexing over TCP connections is proving hard. Consensus seems to be to remove the feature. 2) It _might_ be possible to add the feature back for SCTP. Consensus is not clear on this point. So, is your point that for argument 1 we have failed to consider if MSRP is workable at all without the feature? I think that for the peer-to-peer scenario, the answer to that is trivially identical to any other e2e messaging protocol that uses typical IETF conventions (text based, MIME, etc.) So the question becomes are _relays_ workable without session multiplexing. Before we delve too deep into that, remember why relays are there in the first place: NAT and firewall traversal. The need for multiplexing in the 2 relay case is at least somewhat affected by the percentage of sessions that actually use 2 relays. While I recognize that NATs and restrictive firewalls are not going away very soon, I think that we should strongly discourage the 2 relay scenario except in very specific cases. We _definitely_ should not encumber the protocol with an assumption that the 2 relay scenario is the default deployment. (Yes, I realize there is a lot of wishful thinking in that assertion.) I think the course forward is to assume no session multiplexing. Session multiplexing between relays_can_ be added as a future extension, but such a solution must be completely transparent to the endpoints. SCTP _might_ be a solution, but I doubt it is a _complete_ solution. To make this statement more concrete, consider the discussion in a separate thread on the potential of using e2e TLS across relays. If we commit to that feature, (and I am not trying to judge that in _this_ particular argument) then a follow on connection sharing solution will need to preserve that capability. That won't be a trivial requirement, but is probably not impossible. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 11:46:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18228 for ; Thu, 1 May 2003 11:46:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41FqCQ30423 for simple-archive@odin.ietf.org; Thu, 1 May 2003 11:52:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FqB830420 for ; Thu, 1 May 2003 11:52:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18190 for ; Thu, 1 May 2003 11:45:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGHi-00032L-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:47:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGHi-00032F-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 11:47:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Fq2830396; Thu, 1 May 2003 11:52:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41FpM830361 for ; Thu, 1 May 2003 11:51:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18161 for ; Thu, 1 May 2003 11:44:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGGv-00031k-00 for simple@ietf.org; Thu, 01 May 2003 11:46:57 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19BGGp-0002zJ-00 for simple@ietf.org; Thu, 01 May 2003 11:46:51 -0400 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 h41Fi6GK013275; Thu, 1 May 2003 11:44:06 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 May 2003 10:44:05 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A6475F@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Michael Hammer'" , Adam Roach Cc: "'Dean Willis'" , Adam Roach , "'Simple WG'" Subject: RE: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) 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, 1 May 2003 10:44:02 -0500 Michael Hammer [mailto:mhammer@cisco.com] writes: > My feeling is that this is a transport layer problem and should be > addressed at that level, rather than in an application layer protocol. Which is pretty much the proposal on the table. If you stop trying to use TCP connections for multiple simultaneous sessions, then the transport layer solves it for you. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 12:26:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20811 for ; Thu, 1 May 2003 12:26:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41GWuq07803 for simple-archive@odin.ietf.org; Thu, 1 May 2003 12:32:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GWu807800 for ; Thu, 1 May 2003 12:32:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20787 for ; Thu, 1 May 2003 12:26:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGv8-0003b6-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 12:28:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BGv8-0003ay-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 12:28:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GWj807771; Thu, 1 May 2003 12:32:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GKD805749 for ; Thu, 1 May 2003 12:20:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20045 for ; Thu, 1 May 2003 12:13:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGip-0003Ps-00 for simple@ietf.org; Thu, 01 May 2003 12:15:47 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BGik-0003Od-00 for simple@ietf.org; Thu, 01 May 2003 12:15:42 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41GFTWS020676; Thu, 1 May 2003 12:15:29 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACG24630; Thu, 1 May 2003 12:15:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501120510.00b79fd0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Ben Campbell From: Michael Hammer Subject: RE: [Simple] MSRP: Flow Control Cc: aki.niemi@nokia.com, hgs@cs.columbia.edu, Adam Roach , Paul Kyzivat , james.undery@ntlworld.com, Simple WG In-Reply-To: <1051623570.4476.10.camel@verite.localdomain> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945244@esebe013.ntc.nokia.com> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945244@esebe013.ntc.nokia.com> Mime-Version: 1.0 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: Thu, 01 May 2003 12:15:27 -0400 At 08:39 AM 4/29/2003 -0500, Ben Campbell wrote: >As I mentioned in a previous message, the primary motivation for message >switching is connection sharing. While I recognize that we do not have a >requirements document for this, I think we have had consensus for some >time that connection sharing is a good thing, for reasons of congestion >control and effecient use of a scarce resource (number of TCP >connections) at relays. > >Adam has recently pointed out that this may not really help from a >congestion control viewpoint. If we determine that connection sharing is >not worth the trouble, then it may make sense to revisit the tunneling >relay approach. Subtle question: Is connection sharing with no congestion, and connection sharing with congestion the same thing? For relay-to-relay, a relay could open up new connections any time an existing TCP connection is full and queuing starts to take place (>1), and does not automatically tear down a connection when the queue is empty (for at least some time-out period). There may a middle ground between "every IM session is its own TCP connection" and "all IM sessions share a TCP connection". Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 12:32:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21018 for ; Thu, 1 May 2003 12:32:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41GcDd09090 for simple-archive@odin.ietf.org; Thu, 1 May 2003 12:38:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GcD809087 for ; Thu, 1 May 2003 12:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20992 for ; Thu, 1 May 2003 12:31:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BH0F-0003dR-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 12:33:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BH0E-0003dJ-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 12:33:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Gc2809072; Thu, 1 May 2003 12:38:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GVu807700 for ; Thu, 1 May 2003 12:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20704 for ; Thu, 1 May 2003 12:25:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGqa-0003WY-00 for simple@ietf.org; Thu, 01 May 2003 12:23:48 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19BGqU-0003VY-00 for simple@ietf.org; Thu, 01 May 2003 12:23:42 -0400 Received: from localhost (root@localhost [127.0.0.1]) by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h41GMpFr019657; Thu, 1 May 2003 11:22:51 -0500 (CDT) Subject: RE: [Simple] MSRP: Flow Control From: Ben Campbell To: Michael Hammer Cc: aki.niemi@nokia.com, hgs@cs.columbia.edu, Adam Roach , Paul Kyzivat , james.undery@ntlworld.com, Simple WG In-Reply-To: <4.3.2.7.2.20030501120510.00b79fd0@cia.cisco.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945244@esebe013.ntc.nokia.com> <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945244@esebe013.ntc.nokia.com> <4.3.2.7.2.20030501120510.00b79fd0@cia.cisco.com> Content-Type: text/plain Message-Id: <1051806145.2009.1.camel@dhcp31.dfw.dynamicsoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 01 May 2003 11:22:26 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Thu, 2003-05-01 at 11:15, Michael Hammer wrote: > At 08:39 AM 4/29/2003 -0500, Ben Campbell wrote: > >As I mentioned in a previous message, the primary motivation for message > >switching is connection sharing. While I recognize that we do not have a > >requirements document for this, I think we have had consensus for some > >time that connection sharing is a good thing, for reasons of congestion > >control and effecient use of a scarce resource (number of TCP > >connections) at relays. > > > >Adam has recently pointed out that this may not really help from a > >congestion control viewpoint. If we determine that connection sharing is > >not worth the trouble, then it may make sense to revisit the tunneling > >relay approach. > > Subtle question: Is connection sharing with no congestion, and connection > sharing with congestion the same thing? > > For relay-to-relay, a relay could open up new connections any time an > existing TCP connection is full and queuing starts to take place (>1), and > does not automatically tear down a connection when the queue is empty (for > at least some time-out period). > Certainly, the connection sharing model does not require relays to use only one connection. They could create additional connections based on some local policy, as long as no given session had messages split between the connections, as this would play havoc with delivery order. However, the proposal under discussion is removing _any_ TCP connection sharing. > There may a middle ground between "every IM session is its own TCP > connection" and "all IM sessions share a TCP connection". > > Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 1 12:36:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21152 for ; Thu, 1 May 2003 12:36:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41GgTb09708 for simple-archive@odin.ietf.org; Thu, 1 May 2003 12:42:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GgT809697 for ; Thu, 1 May 2003 12:42:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21134 for ; Thu, 1 May 2003 12:35:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BH4N-0003fv-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 12:38:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BH4M-0003fp-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 12:38:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GgJ809674; Thu, 1 May 2003 12:42:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41GbU808696 for ; Thu, 1 May 2003 12:37:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20965 for ; Thu, 1 May 2003 12:30:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BGzY-0003cs-00 for simple@ietf.org; Thu, 01 May 2003 12:33:04 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BGzS-0003cC-00 for simple@ietf.org; Thu, 01 May 2003 12:32:58 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41GUCWS024831; Thu, 1 May 2003 12:30:12 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACG24848; Thu, 1 May 2003 12:30:11 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501122829.00b55840@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: [Simple] MSRP: Towards closure on HoL blocking issue Cc: Dean Willis , "'David R. Oran'" , "'Ben Campbell'" , "'Robert Sparks'" , "'Adam Roach'" , "'Paul Kyzivat'" , "'Cullen Jennings'" , "'Simple WG'" In-Reply-To: <3EAF54AD.9040804@dynamicsoft.com> References: <000c01c30e80$f2dae3a0$ee036e3f@txdwillis> <000c01c30e80$f2dae3a0$ee036e3f@txdwillis> Mime-Version: 1.0 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: Thu, 01 May 2003 12:30:10 -0400 This conclusion is good. Also, doesn't Henning's form of connection re-use at least partially address Cullen's concern? Mike At 12:44 AM 4/30/2003 -0400, Jonathan Rosenberg wrote: >I concur with Dave and Dean here. Let us have no restriction on message >sizes, and have relays use a different connection for each session. We >should be sure to mention the idea Henning mentioned of holding on to >connections after the sessions terminate, so they can then be reused >for subsequent sessions. > >Furthermore, I don't even see the real troubles with supporting SCTP now. >I would not make it mandatory; I would rather say that everyone MUST to >TCP and MAY do SCTP. From rfc3264 we have a pretty good handle on how to >support discovery for URIs that can run on multiple transports. > >-Jonathan R. > > >Dean Willis wrote: >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of >>>David R. Oran >>>Sent: Tuesday, April 29, 2003 10:14 AM >>>To: Ben Campbell; Robert Sparks; Adam Roach; Jonathan Rosenberg; Paul >>>Kyzivat; Cullen Jennings >>>Cc: Simple WG >>>Subject: Re: [Simple] MSRP: Towards closure on HoL blocking issue >>> >>> >>>Sorry if I'm jumping in late. I much prefer to KISS and do nothing, as >>>proposed by Henning. If we want to multilex transport connections in the >>>future for relays, do it with SCTP and have one stream per client session. >>> >>>Dave. >> >>Ok, let's see if I have this right: >>1) We don't mux with TCP. Ever. >>2) We don't size-limit. >>3) If your session gets congested because you sent a huge message, it's your >>fault, deal with it, and it shouldn't be bothering anybody else because it's >>on its own stream somewhere. >>4) Everything works fine, but we've reduced the capacity of relays by >>something less than 50%. >>I'm happy with that. It beats trying to explain queuing theory to Adam, >>especially since he's smarter than I am. >>-- >>dean > >-- >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Chief Scientist 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 mailnull@www1.ietf.org Thu May 1 13:21:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23626 for ; Thu, 1 May 2003 13:21:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41HROI20565 for simple-archive@odin.ietf.org; Thu, 1 May 2003 13:27:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41HRO820562 for ; Thu, 1 May 2003 13:27:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23619 for ; Thu, 1 May 2003 13:20:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHlp-0004Bz-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 13:22:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BHlo-0004Bw-00 for simple-web-archive@ietf.org; Thu, 01 May 2003 13:22:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41HRC820551; Thu, 1 May 2003 13:27:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41HQW820401 for ; Thu, 1 May 2003 13:26:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23573 for ; Thu, 1 May 2003 13:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BHkz-0004BH-00 for simple@ietf.org; Thu, 01 May 2003 13:22:05 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19BHkt-0004B0-00 for simple@ietf.org; Thu, 01 May 2003 13:21:59 -0400 Received: from cia.cisco.com (IDENT:mirapoint@cia.cisco.com [64.100.238.51]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41HLdWS009823; Thu, 1 May 2003 13:21:40 -0400 (EDT) Received: from mhammer-w2k02.cisco.com (dhcp-hrn-64-100-229-133.cisco.com [64.100.229.133]) by cia.cisco.com (Mirapoint) with ESMTP id ACG25561; Thu, 1 May 2003 13:21:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501131912.058c6ef0@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: Re: [Simple] Re: MSRP Requirements Cc: Paul Kyzivat , Ben Campbell , "David R. Oran" , Robert Sparks , Adam Roach , Cullen Jennings , Simple WG In-Reply-To: <3EAF52DC.2030405@dynamicsoft.com> References: <3EAEE759.8010708@cisco.com> <1051557511.2721.28.camel@verite.localdomain> <418788115.1051614834@ORANLT.dhcp110.enet.interop.net> <1051631885.1568.24.camel@dhcp31.dfw.dynamicsoft.com> <3EAED978.40501@cisco.com> <3EAEE759.8010708@cisco.com> Mime-Version: 1.0 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: Thu, 01 May 2003 13:21:37 -0400 At 12:36 AM 4/30/2003 -0400, Jonathan Rosenberg wrote: >>4) Be effective in delivering messages of all sizes, up to and >>including multi-gigabyte messages. (How much of a requirement is >>this???) > >It is an important requirement. At what point does one then declare FTP to be obsolete? That is, what is the difference between FTPing and IMing? >If this particular requirement is causing a serious problem with other >requirements - i.e., message size limits, DoS attacks, etc., I would dump >this in favor of others. After all, our preferred model is e2e >connections, where there would be no connection sharing at all between >endpoints. Once you insert relays, can you still claim that it is e2e? Mike _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 2 01:20:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25046 for ; Fri, 2 May 2003 01:20:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h425QRk09722 for simple-archive@odin.ietf.org; Fri, 2 May 2003 01:26:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h425QR809719 for ; Fri, 2 May 2003 01:26:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25036 for ; Fri, 2 May 2003 01:19:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BSzR-00026g-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 01:21:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BSzQ-00026d-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 01:21:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h425QH809710; Fri, 2 May 2003 01:26:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h425PS809675 for ; Fri, 2 May 2003 01:25:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25014 for ; Fri, 2 May 2003 01:18:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BSyE-00026K-00 for simple@ietf.org; Fri, 02 May 2003 01:20:30 -0400 Received: from [203.194.209.81] (helo=website12.com) by ietf-mx with smtp (Exim 4.12) id 19BSy3-00026H-00 for simple@ietf.org; Fri, 02 May 2003 01:20:19 -0400 Received: (qmail 4304 invoked by uid 501); 2 May 2003 05:21:01 -0000 Message-ID: <20030502052101.13133.qmail@website12.com> Reply-To: "=?iso-8859-1?B?c3VicmFtYW55YW0=?=" From: "=?iso-8859-1?B?c3VicmFtYW55YW0=?=" To: simple@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_b83c9f469301a7ecc29a373d4c2079b2d" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: WebMail 2.2 Subject: [Simple] Query regarding Watcher List Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 02 May 2003 05:21:01 --_b83c9f469301a7ecc29a373d4c2079b2d Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWxsLA0KICAgICAgSSBoYXZlIGEgcXVlcnkgaW4gUHJlc2VuY2UgU2VydmljZS4NCg0KMSlX aGVuZXZlciBhIGNsaWVudChwcmVzZW50aXR5KSBsb2dzIGluLGhvdyB3aWxsIGhlIGRvd25sb2Fk IHRoZSB3YXRjaGVyIGxpc3QNCm9yIGJlIGluZm9ybWVkIG9mIHRoZSB3YXRjaGVycyB3aG8gaGF2 ZSBwcmV2aW91c2x5IHdhdGNoZWQgaGltLi4/DQoNCllvdXJzIGZyaWVuZGx5LA0KDQpWLlN1YnJh bWFueWFtCg== --_b83c9f469301a7ecc29a373d4c2079b2d Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PGh0bWw+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4KPC9oZWFkPgo8Ym9keT4KSGkgQWxsLA08YnI+ CiAgICAgIEkgaGF2ZSBhIHF1ZXJ5IGluIFByZXNlbmNlIFNlcnZpY2UuDTxicj4KDTxicj4KMSlX aGVuZXZlciBhIGNsaWVudChwcmVzZW50aXR5KSBsb2dzIGluLGhvdyB3aWxsIGhlIGRvd25sb2Fk IHRoZSB3YXRjaGVyIGxpc3QNPGJyPgpvciBiZSBpbmZvcm1lZCBvZiB0aGUgd2F0Y2hlcnMgd2hv IGhhdmUgcHJldmlvdXNseSB3YXRjaGVkIGhpbS4uPw08YnI+Cg08YnI+CllvdXJzIGZyaWVuZGx5 LA08YnI+Cg08YnI+ClYuU3VicmFtYW55YW08YnI+CjwvYm9keT48L2h0bWw+Cg== --_b83c9f469301a7ecc29a373d4c2079b2d-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 2 02:35:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07656 for ; Fri, 2 May 2003 02:35:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h426fVS26214 for simple-archive@odin.ietf.org; Fri, 2 May 2003 02:41:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426fU826211 for ; Fri, 2 May 2003 02:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07639 for ; Fri, 2 May 2003 02:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BUA2-0002dU-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 02:36:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BUA2-0002dR-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 02:36:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426fJ826202; Fri, 2 May 2003 02:41:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h426e3826090 for ; Fri, 2 May 2003 02:40:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07622 for ; Fri, 2 May 2003 02:32:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BU8O-0002d9-00 for simple@ietf.org; Fri, 02 May 2003 02:35:04 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19BU8I-0002cx-00 for simple@ietf.org; Fri, 02 May 2003 02:34:58 -0400 Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h426Yrdh005670; Fri, 2 May 2003 02:34:53 -0400 (EDT) Message-ID: <3EB21189.6060701@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: subramanyam CC: simple@ietf.org Subject: Re: [Simple] Query regarding Watcher List References: <20030502052101.13133.qmail@website12.com> In-Reply-To: <20030502052101.13133.qmail@website12.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, 02 May 2003 02:34:49 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is done using watcherinfo. See: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-package-05.txt -Jonathan R. subramanyam wrote: > Hi All, > I have a query in Presence Service. > > 1)Whenever a client(presentity) logs in,how will he download the watcher > list > or be informed of the watchers who have previously watched him..? > > Yours friendly, > > V.Subramanyam -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Fri May 2 03:58:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08738 for ; Fri, 2 May 2003 03:58:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4284VH31505 for simple-archive@odin.ietf.org; Fri, 2 May 2003 04:04:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4284U831502 for ; Fri, 2 May 2003 04:04:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08734 for ; Fri, 2 May 2003 03:57:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BVSK-0002yF-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 03:59:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BVSK-0002y6-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 03:59:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4284H831480; Fri, 2 May 2003 04:04:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4283J831435 for ; Fri, 2 May 2003 04:03:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08718 for ; Fri, 2 May 2003 03:56:22 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BVRB-0002xn-00 for simple@ietf.org; Fri, 02 May 2003 03:58:34 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19BVR6-0002xh-00 for simple@ietf.org; Fri, 02 May 2003 03:58:28 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h427wiD08699 for ; Fri, 2 May 2003 10:58:44 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 May 2003 10:58:45 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 2 May 2003 10:58:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD5C3@esebe013.ntc.nokia.com> Thread-Topic: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) Thread-Index: AcMPX9RfzoG832GeT1aNsaKyZuuaxwBHZ6dA To: , Cc: , X-OriginalArrivalTime: 02 May 2003 07:58:44.0360 (UTC) FILETIME=[A7348080:01C31080] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4283K831436 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 2 May 2003 10:58:42 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Inline. > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 01 May, 2003 00:27 > To: Adam Roach > Cc: Ben Campbell; Simple WG > Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards > clos ure on HoL blocking issue) > > > > > Adam Roach wrote: > > Ben Campbell writes: > > > > > >>Jonathan suggested we should handle flow control by simply dropping > >>messages. This is not as heinous as it first sounds, since > MSRP does > >>have e2e acknowledgement of message delivery. > > > > > > The prospect of designing yet another protocol that needs to > > retransmit requests over a *reliable* transport layer if > > no response is received makes me more than a little queasy. > > You beat me to it - my stomach has been bothering me for awhile too. > > I'm trying to remember why we put the end-to-end acks in. > I'm quite sure > it wasn't so we could drop messages with the expectation > that the sender > would retry them. I think maybe it was so the sender can > detect when the > other end fails. For testing endpoint liveliness, I think it is better to make it explicit rather than implicit. Defining new methods to do this (like PING/PONG in IRC) is better because an endpoint can then be tested even when there are no IMs to send. Another suggestion was to use the VISIT request to refresh the connection. Cheers, Aki > > 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 mailnull@www1.ietf.org Fri May 2 11:30:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17963 for ; Fri, 2 May 2003 11:30:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42FbTL31538 for simple-archive@odin.ietf.org; Fri, 2 May 2003 11:37:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42FbS831527 for ; Fri, 2 May 2003 11:37:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17957 for ; Fri, 2 May 2003 11:30:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BcWX-00050W-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 11:32:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BcWW-00050R-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 11:32:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42FbH831291; Fri, 2 May 2003 11:37:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42FaT830847 for ; Fri, 2 May 2003 11:36:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17909 for ; Fri, 2 May 2003 11:29:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BcVL-0004zU-00 for simple@ietf.org; Fri, 02 May 2003 11:31:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19BcVE-0004zF-00 for simple@ietf.org; Fri, 02 May 2003 11:31:13 -0400 Received: from localhost (root@localhost [127.0.0.1]) by magus.nostrum.com (8.12.8/8.12.8) with ESMTP id h42FUjFr033905; Fri, 2 May 2003 10:30:45 -0500 (CDT) Subject: RE: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards clos ure on HoL blocking issue) From: Ben Campbell To: aki.niemi@nokia.com Cc: Paul Kyzivat , Adam Roach , Simple WG In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD5C3@esebe013.ntc.nokia.com> References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901ADD5C3@esebe013.ntc.nokia.com> Content-Type: text/plain Message-Id: <1051889378.1582.2.camel@dhcp31.dfw.dynamicsoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 02 May 2003 10:29:39 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2003-05-02 at 02:58, aki.niemi@nokia.com wrote: > Inline. > > > -----Original Message----- > > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: 01 May, 2003 00:27 > > To: Adam Roach > > Cc: Ben Campbell; Simple WG > > Subject: Re: MSRP: Connection Sharing (was Re: [Simple] MSRP: Towards > > clos ure on HoL blocking issue) > > > > > > > > > > Adam Roach wrote: > > > Ben Campbell writes: > > > > > > > > >>Jonathan suggested we should handle flow control by simply dropping > > >>messages. This is not as heinous as it first sounds, since > > MSRP does > > >>have e2e acknowledgement of message delivery. > > > > > > > > > The prospect of designing yet another protocol that needs to > > > retransmit requests over a *reliable* transport layer if > > > no response is received makes me more than a little queasy. > > > > You beat me to it - my stomach has been bothering me for awhile too. > > > > I'm trying to remember why we put the end-to-end acks in. > > I'm quite sure > > it wasn't so we could drop messages with the expectation > > that the sender > > would retry them. I think maybe it was so the sender can > > detect when the > > other end fails. > > For testing endpoint liveliness, I think it is better to make it explicit rather than implicit. Defining new methods to do this (like PING/PONG in IRC) is better because an endpoint can then be tested even when there are no IMs to send. Another suggestion was to use the VISIT request to refresh the connection. > Both VISIT and BIND will be soft state (i.e. refreshed) in the next revision. > Cheers, > Aki > > > > > > 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 mailnull@www1.ietf.org Fri May 2 12:43:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20109 for ; Fri, 2 May 2003 12:43:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Gnls05406 for simple-archive@odin.ietf.org; Fri, 2 May 2003 12:49:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Gnl805403 for ; Fri, 2 May 2003 12:49:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20090 for ; Fri, 2 May 2003 12:42:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdeU-0005X7-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 12:44:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BdeT-0005X3-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 12:44:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GnE805375; Fri, 2 May 2003 12:49:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42GmK805342 for ; Fri, 2 May 2003 12:48:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20071 for ; Fri, 2 May 2003 12:41:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Bdd0-0005WO-00 for simple@ietf.org; Fri, 02 May 2003 12:43:18 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Bdcf-0005WI-00 for simple@ietf.org; Fri, 02 May 2003 12:42:57 -0400 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 h42Ggn906713 for ; Fri, 2 May 2003 11:42:49 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1051893687.1109.51.camel@ds.sipit.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLEt Report Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 02 May 2003 10:41:28 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This week's SIMPLEt was very successful. We had around a dozen implementations from 9 attending teams. We successfully exercised many Event: presence subscription use cases, including - use of TLS between 4 implementations - interoperable exchange and use of application/cpim-pidf+xml documents with private extensions - Subscriptions established by a NOTIFY arriving before the 2xx-SUBSCRIBE - servers shortening subscriptions in NOTIFYs beyond the initial NOTIFY - Forked SUBSCRIBEs We successfully exercised text-plain MESSAGE exchange. We also successfully exercised a pair of early implementations of PUBLISH. We discovered a need to clarify the definition of "dialog-establishing NOTIFY" and build a better description of when a subscriptions should be terminated based on NOTIFY error responses. (Recoverable errors such as 401 or 420 should not destroy the subscription). We addressed an interesting question: What do you do when the set of types in the Accept: set for dialog changes and you find yourself needing to send a NOTIFY but can no longer generate an Accept-able document. The consensus was to terminate the subscription with reason="deactivated" to stimulate a new SUBSCRIBE so a new Accept set can be established. There were a few client implementation errors handling the NOTIFYs generated by a forked SUBSCRIBE, resulting in multiple dialogs being established. The consequences of those errors were shown to be contained within the erroneous element. There was no significant testing of Event: presence.winfo and there was no testing of event-lists or RPIDs at this event. Having sufficient implementations to focus on those concepts at SIPIT 13 looks promising. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 2 13:51:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22910 for ; Fri, 2 May 2003 13:51:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42Hw9g11151 for simple-archive@odin.ietf.org; Fri, 2 May 2003 13:58:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Hw9811148 for ; Fri, 2 May 2003 13:58:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22887 for ; Fri, 2 May 2003 13:51:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BeiY-00066l-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 13:53:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19BeiD-00066S-00 for simple-web-archive@ietf.org; Fri, 02 May 2003 13:52:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HvE811067; Fri, 2 May 2003 13:57:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42HuU811025 for ; Fri, 2 May 2003 13:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22827 for ; Fri, 2 May 2003 13:49:22 -0400 (EDT) From: krisztian.kiss@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Begx-00065o-00 for simple@ietf.org; Fri, 02 May 2003 13:51:27 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19BegX-00065V-00 for simple@ietf.org; Fri, 02 May 2003 13:51:01 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h42Hp2D20098 for ; Fri, 2 May 2003 20:51:02 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 2 May 2003 20:51:03 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 2 May 2003 20:51:02 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 2 May 2003 20:51:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt Message-ID: Thread-Topic: [Simple] Comments on draft-ietf-simple-data-req-02.txt Thread-Index: AcMLWjgklYRv+iOORKK1rCGOICaepAFZ+4MA To: , Cc: X-OriginalArrivalTime: 02 May 2003 17:51:02.0054 (UTC) FILETIME=[65524460:01C310D3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h42HuU811026 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 2 May 2003 20:51:00 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Jonathan et al, Please find below some comments on draft-ietf-simple-data-req-02: - REQ PC-9 defines that a user could query for a "set of URIs" of a collection. I believe this kind of query should return all information available for the presentity collection in addition to the set of URIs. Additionally, the REQ should also define those users who are authorized to make this query. According to PC-10 and PC-11, there are already two kind of authorized lists defined, one list is for the users who are allowed to subscribe to the list, another list is for the users who are allowed to manipulate the attributes of the list. Probably the group of the users allowed to query equals to the group who are allowed to subscribe. One re-wording of the sentence could be as follows: "It MUST be possible for the authorized users allowed to subscribe to the list also to query for information of the particular presentity collection by providing the URI for the presentity collection." -REQ PC-24: I am wondering about the justification for this REQ. It sounds rather an implementation issue instead of a requirement that would have effects on the final solution. It might cause unnecessary and additional complexity for the solution. To tell the truth, I am confused why the network resident address book has some special role here, if this is the case, we could also have REQs for other type of "collection kind of resources", e.g. presence access list, etc. Anyway, it'd good to have a more generic REQ instead, with a strength SHOULD instead of MUST. -REQ AP-7: I believe there is no need for this requirement. In the requirement phase, the best would be to keep distinct roles for the different lists, the buddy list is for the presentity's own subscription purposes, the allowed and blocked lists are for authorization purposes. -REQ AP-8: would be good to have more exact wording in the last sentence of the requirement. I guess the assumption here is that the meaning behind the "add, remove, modify, read, clear and create and delete" operations must be clear for the reader based on the PC requirements, however here we are talking about multiple lists, therefore it is unclear whether the remove, delete and clear operations are meant for the individual entries of a list, the list itself, or all the lists handled by the authorization policy. -REQ N1-5: all the notification requirements listed in chapter 5.2 are somehow "less important". If we can set "when" type of requirements (criteria when notifications are delivered to watchers) also to authorization, additionally to filtering, throttling and local server policies, we may end up having too complex rules about generating notifications. -REQ C1-3: These requirements seem too specific and rather unclear. The first issue is why only the contact address and status are chosen as presence attributes that the user can set by authorization. Maybe a generic requirement would be enough saying that the authorized content could be specified by using any presence attribute. The second issue, which is rather important, if these requirements mean that after authorization the whole tuple including the attribute is omitted, or only the chosen attribute from the tuple. More clearly, is the aim to allow for the user to define which presence attributes to authorize within a tuple or rather to authorize tuples (i.e. what is the atomic element handled by the content policy)? -REQ C-4: I guess it would be better to place this before C1-3. Assuming that the previous requirements were meant for selecting attributes within a tuple, this REQ seem to allow to select a whole tuple. Does this requirement allow any presence attribute (e.g. one RPIDS extensions, tuple-id) to be used as a criteria for selecting the tuples? -REQ C-6: this REQ sounds like one covering the delivery of default presence documents. I would prefer to mention here explicitly that DM is used for publication of the default presence document. Also, a strength of MUST would be better instead of the SHOULD. A rewording could be: It MUST be possible for the user to publish a presence document with default presence attributes. Additional requirements: -REQ-PC-x: A requirement about storing an XML document including filtering information by using the data manipulation mechanism. This could be useful for presentity collections where different URIs of the collection could have either common or individual filter definitions pre-defined, and the watcher(s) would not need to include any filter information within the subscription. -REQ AP-x: A requirement might be justified for the expected behavior of the acceptance policy when a watcher is part of several lists, e.g. multiple allowed lists. The policy could define, for example, an evaluation order for the lists, and the policy would stop evaluating the lists when the particular watcher is found. An alternative could be that the watcher cannot belong to several lists, however this does not sound feasible, especially if it is possible to use wildcards for defining URIs. -REQ C-x: A requirement, when the presentity authorizes different values of the otherwise same "data segment" to different watchers. One motivation here is the ability to give different level of details of information (e.g. w.r.t. location) to different watchers. Perhaps this is hidden behind some of the requirements, but it would be rather good to explicitly state it. REQ C-5 covers this partly, however it makes a hint that new values of attributes are to be modified from existing values. By taking the geographical location information example, the difference between the information to be delivered to different watchers is only in the level of details. Therefore, there could be another approach that tuples would be assigned for the different level of details and authorization would be done based on some kind of "level of detail" attribute. -REQ ?-x: Relation between the content requirements and the acceptance policy requirements are somehow undefined. When the acceptance policy results in accepting a watcher, then which content/notification requirements shall be applied, how and where this relation would be defined. Thanks, Krisztian _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon May 5 17:17:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16615 for ; Mon, 5 May 2003 17:17:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45LQ1N03968 for simple-archive@odin.ietf.org; Mon, 5 May 2003 17:26:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45LQ1803965 for ; Mon, 5 May 2003 17:26:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16590 for ; Mon, 5 May 2003 17:17:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CnMt-00010h-00 for simple-web-archive@ietf.org; Mon, 05 May 2003 17:19:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CnMs-00010Y-00 for simple-web-archive@ietf.org; Mon, 05 May 2003 17:19:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45LPT803926; Mon, 5 May 2003 17:25:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45LDF803305 for ; Mon, 5 May 2003 17:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16285 for ; Mon, 5 May 2003 17:04:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CnAI-0000wh-00 for simple@ietf.org; Mon, 05 May 2003 17:06:26 -0400 Received: from oe-im1pub.managedmail.com ([206.46.164.52] helo=oe-im1.bizmailsrvcs.net) by ietf-mx with esmtp (Exim 4.12) id 19CnAD-0000wS-00 for simple@ietf.org; Mon, 05 May 2003 17:06:21 -0400 Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-im1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with ESMTP id <20030505210615.OXBW2597.oe-im1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Mon, 5 May 2003 16:06:15 -0500 Received: from tdiacakis ([63.67.207.249]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.05.27 201-253-122-126-127-20021220) with SMTP id <20030505210614.ZFXY316.oe-ismta1.bizmailsrvcs.net@tdiacakis>; Mon, 5 May 2003 16:06:14 -0500 Message-ID: <02ca01c3134a$28d0dc30$1d40100a@myopwv.com> From: "Thanos Diacakis" To: "Simple WG" , "Avshalom Houri" References: Subject: Re: [Simple] SIMPLE arch document 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: Mon, 5 May 2003 15:06:00 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Quick thought: Perhaps arranging the relevant drafts (in Section 5) by functionality and not by working group would make it more useful for those looking to implement SIMPLE-based system, who might not care for the historical intricacies of IETF, IMPP, etc. Thanos --- Thanos Diacakis Openwave Systems thanos.diacakis@openwave.com +1-303 385 6705 ----- Original Message ----- From: "Avshalom Houri" To: "Simple WG" Sent: Thursday, May 01, 2003 6:03 AM Subject: [Simple] SIMPLE arch document > The SIMPLE charter specifies the following deliverable: > > "An architecture for the implementation of a traditional buddylist- > based instant messaging and presence application with SIP, including > for example new mechanisms for message confirmation delivery, indications > for when a party is in the process of typing a message, secure buddylist > manipulation operations, and the extension of the CPIM presence format > to describe typical IM states." > > We have submitted a (very) initial skeleton document for the above: > > http://www.ietf.org/internet-drafts/draft-houri-simple-arch-00.txt > > I know that the document tries to cover much more then what was intended. > However, in order to continue working on the document we would like to get > some feedback from the group. > > Any input will be appreciated. > > Thanks > Avshalom > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue May 6 01:24:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27002 for ; Tue, 6 May 2003 01:24:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h465Wd403326 for simple-archive@odin.ietf.org; Tue, 6 May 2003 01:32:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h465Wc803323 for ; Tue, 6 May 2003 01:32:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26996 for ; Tue, 6 May 2003 01:23:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cuxe-0003Cl-00 for simple-web-archive@ietf.org; Tue, 06 May 2003 01:25:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Cuxd-0003Ci-00 for simple-web-archive@ietf.org; Tue, 06 May 2003 01:25:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h465TH803187; Tue, 6 May 2003 01:29:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h465SP803163 for ; Tue, 6 May 2003 01:28:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26945 for ; Tue, 6 May 2003 01:19:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CutJ-0003C2-00 for simple@ietf.org; Tue, 06 May 2003 01:21:26 -0400 Received: from d12lmsgate-3.de.ibm.com ([194.196.100.236]) by ietf-mx with esmtp (Exim 4.12) id 19CutD-0003Bs-00 for simple@ietf.org; Tue, 06 May 2003 01:21:20 -0400 Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (8.12.9/8.12.8) with ESMTP id h465LDCi035736 for ; Tue, 6 May 2003 07:21:13 +0200 Received: from d10ml001.telaviv.ibm.com (d10ml001.telaviv.ibm.com [9.148.216.55]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h465LDwd291270 for ; Tue, 6 May 2003 07:21:13 +0200 To: simple@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0 September 26, 2002 Message-ID: From: "Avshalom Houri" X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 5.0.9a |January 7, 2002) at 06/05/2003 08:21:07, Serialize complete at 06/05/2003 08:21:07 Content-Type: text/plain; charset="US-ASCII" Subject: [Simple] PUBLISH and REGISTER relationship Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 6 May 2003 08:21:02 +0300 In a system that has both a registrar and a presence server what should be the relationships between REGISTER and PUBLISH? * Should a REGISTER make the user on-line even though PUBLISH was not sent yet? * Should PUBLISH be considered as a login to the system as REGISTER? To some extent it seems that PUBLISH and REGISTER have a similar functionality but one is for the registrar while the other is for the presence server. Avshalom _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue May 6 11:14:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25677 for ; Tue, 6 May 2003 11:14:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46FMXr31917 for simple-archive@odin.ietf.org; Tue, 6 May 2003 11:22:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46FMX831914 for ; Tue, 6 May 2003 11:22:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25629 for ; Tue, 6 May 2003 11:13:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D4AK-0007fe-00 for simple-web-archive@ietf.org; Tue, 06 May 2003 11:15:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D4AJ-0007fb-00 for simple-web-archive@ietf.org; Tue, 06 May 2003 11:15:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46FMN831895; Tue, 6 May 2003 11:22:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46FLk831863 for ; Tue, 6 May 2003 11:21:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25589 for ; Tue, 6 May 2003 11:12:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D49Z-0007en-00 for simple@ietf.org; Tue, 06 May 2003 11:14:49 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19D49Y-0007cQ-00 for simple@ietf.org; Tue, 06 May 2003 11:14:48 -0400 Received: from localhost (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h46FD38w042552; Tue, 6 May 2003 10:13:04 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] PUBLISH and REGISTER relationship From: Ben Campbell To: Avshalom Houri Cc: Simple WG In-Reply-To: References: Content-Type: text/plain Message-Id: <1052233971.1587.1.camel@dhcp31.dfw.dynamicsoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 06 May 2003 10:12:51 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think that is entirely a question of local policy. There is no protocol requirement for the two operations to be linked in any way, but a given service provider might choose to do so. If you _do_ link them, you are making assumptions about a relationship between the device doing the publishing and the device doing the registering that may or may not exist. On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: > In a system that has both a registrar and a presence server what should be > the relationships between > REGISTER and PUBLISH? > > * Should a REGISTER make the user on-line even though PUBLISH was not sent > yet? > * Should PUBLISH be considered as a login to the system as REGISTER? > > To some extent it seems that PUBLISH and REGISTER have a similar > functionality but one is for the registrar > while the other is for the presence server. > > Avshalom > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 7 06:09:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22633 for ; Wed, 7 May 2003 06:09:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47AIFl00679 for simple-archive@odin.ietf.org; Wed, 7 May 2003 06:18:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47AIF800672 for ; Wed, 7 May 2003 06:18:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22627 for ; Wed, 7 May 2003 06:08:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DLt0-00073j-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 06:10:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DLsz-00073f-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 06:10:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47AI8800654; Wed, 7 May 2003 06:18:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47AHs800637 for ; Wed, 7 May 2003 06:17:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22614 for ; Wed, 7 May 2003 06:08:29 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DLsf-00073T-00 for simple@ietf.org; Wed, 07 May 2003 06:10:33 -0400 Received: from imo-d03.mx.aol.com ([205.188.157.35]) by ietf-mx with esmtp (Exim 4.12) id 19DLsf-00073C-00 for simple@ietf.org; Wed, 07 May 2003 06:10:33 -0400 Received: from AndrewAllen007@aol.com by imo-d03.mx.aol.com (mail_out_v34.22.) id l.28.37bd635d (15865); Wed, 7 May 2003 06:10:39 -0400 (EDT) Received: from aol.com (mow-m05.webmail.aol.com [64.12.184.133]) by air-id06.mx.aol.com (v93.12) with ESMTP id MAILINID64-3df93eb8db9e2fc; Wed, 07 May 2003 06:10:38 2000 To: simple@ietf.org Cc: AndrewAllen007@aol.com MIME-Version: 1.0 Message-ID: <37B46C91.12CFE9A7.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 Subject: [Simple] [SIMPLE]Comment on draft-schulzrinne-simple-rpids-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, 07 May 2003 06:10:38 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h47AI8800654 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47AIF800672 Content-Transfer-Encoding: 8bit I have a comment regarding the defined list of Category Indications in clause 6.6 of draft-schulzrinne-simple-rpids-01. While the current list seems to cover what we spend much of our time on during the day it does not include something we all spend a quarter to a third of each day doing – sleeping. I propose that “Sleeping” be added to the list as one of the standardized Category indications in the next version of this draft. I observe in current presence Applications that I often see user text added such as “ZZzzzzzz” or even “dreams of bis” etc so it seems commonly useful to indicate to others the sleep state. Obviously a sleeping person only wants to be awoken in a genuine emergency can’t wait situation. Many mobile phones include alarm clocks and the sleeping state could be derived automatically when the alarm is set as could the until element (to the time of wakeup). Transition out of this status could also be triggered by the wake up alarm event itself. Frequent international travelers would find such an indication very useful in avoiding those unwanted wakeups because of time zone differences with the office etc. I think the sleeping state is quite different from busy as your boss may consider that you are never too busy to talk to him – however waking you up is another thing entirely. Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 7 07:26:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24219 for ; Wed, 7 May 2003 07:26:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47BZNW05782 for simple-archive@odin.ietf.org; Wed, 7 May 2003 07:35:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BZN805778 for ; Wed, 7 May 2003 07:35:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24169 for ; Wed, 7 May 2003 07:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DN5c-0007OR-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 07:28:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DN5U-0007O5-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 07:27:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BZ9805663; Wed, 7 May 2003 07:35:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BOZ805099 for ; Wed, 7 May 2003 07:24:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23778; Wed, 7 May 2003 07:15:08 -0400 (EDT) Message-Id: <200305071115.HAA23778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-event-list-02.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: Wed, 07 May 2003 07:15:08 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists Author(s) : A. Roach, J. Rosenberg, B. Campbell Filename : draft-ietf-simple-event-list-02.txt Pages : 41 Date : 2003-5-6 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 subscribe to an entire list, and then receive notifications when the state of any of the resources in the list changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-02.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 "get draft-ietf-simple-event-list-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-event-list-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-6153422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-event-list-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-event-list-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153422.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 7 07:26:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24221 for ; Wed, 7 May 2003 07:26:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47BZNh05801 for simple-archive@odin.ietf.org; Wed, 7 May 2003 07:35:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BZN805798 for ; Wed, 7 May 2003 07:35:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24175 for ; Wed, 7 May 2003 07:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DN5c-0007OS-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 07:28:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DN5U-0007OF-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 07:27:52 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BZB805681; Wed, 7 May 2003 07:35:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BOf805105 for ; Wed, 7 May 2003 07:24:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23794; Wed, 7 May 2003 07:15:14 -0400 (EDT) Message-Id: <200305071115.HAA23794@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-presinfo-deliv-reg-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: Wed, 07 May 2003 07:15:14 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Efficient Delivery of Presence Information Author(s) : M. Lonnfors et al. Filename : draft-ietf-simple-presinfo-deliv-reg-00.txt Pages : 9 Date : 2003-5-6 A Presence service implemented using SIMPLE has some constraints for delivering presence information to devices with low data processing capabilities, small display, and limited battery power. Other limitations can be caused by the interface between the terminal and the network, i.e. if presence information is delivered over radio links with high latency and low bandwidth. This memo presents requirements for a solution that can aid to reduce the impacts of these constrains and helps to increase efficiency. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-presinfo-deliv-reg-00.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 "get draft-ietf-simple-presinfo-deliv-reg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-presinfo-deliv-reg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-6153431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-presinfo-deliv-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-presinfo-deliv-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-6153431.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 7 07:55:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25524 for ; Wed, 7 May 2003 07:55:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47C4uC08167 for simple-archive@odin.ietf.org; Wed, 7 May 2003 08:04:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47C4u808164 for ; Wed, 7 May 2003 08:04:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25510 for ; Wed, 7 May 2003 07:55:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DNYD-0007mO-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 07:57:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DNYC-0007mL-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 07:57:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47C36808102; Wed, 7 May 2003 08:03:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47C2N808075 for ; Wed, 7 May 2003 08:02:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25459 for ; Wed, 7 May 2003 07:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DNVk-0007lc-00 for simple@ietf.org; Wed, 07 May 2003 07:55:00 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19DNVj-0007lZ-00 for simple@ietf.org; Wed, 07 May 2003 07:54:59 -0400 Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h47Btp51025117 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 7 May 2003 07:55:51 -0400 (EDT) Message-ID: <3EB8F40A.4080903@cs.columbia.edu> From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: AndrewAllen007@aol.com CC: simple@ietf.org Subject: Re: [Simple] [SIMPLE]Comment on draft-schulzrinne-simple-rpids-01 References: <37B46C91.12CFE9A7.2E6F5200@aol.com> In-Reply-To: <37B46C91.12CFE9A7.2E6F5200@aol.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) X-MIME-Autoconverted: from 8bit to quoted-printable by marionberry.cc.columbia.edu id h47Btp51025117 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47C2N808076 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 07 May 2003 07:54:50 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h47C36808102 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47C4u808164 Content-Transfer-Encoding: 8bit > > While the current list seems to cover what we spend much of our time on during the day it does not include something we all spend a quarter to a third of each day doing – sleeping. > > I propose that “Sleeping” be added to the list as one of the standardized Category indications in the next version of this draft. Noted. > > I observe in current presence Applications that I often see user text added such as “ZZzzzzzz” or even “dreams of bis” etc so it seems commonly useful to indicate to others the sleep state. Obviously a sleeping person only wants to be awoken in a genuine emergency can’t wait situation. > > Many mobile phones include alarm clocks and the sleeping state could be derived automatically when the alarm is set as could the until element (to the time of wakeup). Transition out of this status could also be triggered by the wake up alarm event itself. Frequent international travelers would find such an indication very useful in avoiding those unwanted wakeups because of time zone differences with the office etc. > > I think the sleeping state is quite different from busy as your boss may consider that you are never too busy to talk to him – however waking you up is another thing entirely. Does the powernap count :-)? > > Andrew > > _______________________________________________ > 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 mailnull@www1.ietf.org Wed May 7 13:42:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09717 for ; Wed, 7 May 2003 13:42:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Hpjm06106 for simple-archive@odin.ietf.org; Wed, 7 May 2003 13:51:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Hpi806103 for ; Wed, 7 May 2003 13:51:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09708 for ; Wed, 7 May 2003 13:42:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSxi-0003ER-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 13:44:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DSxh-0003EO-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 13:44:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47HpY806088; Wed, 7 May 2003 13:51:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Hof806060 for ; Wed, 7 May 2003 13:50:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09696 for ; Wed, 7 May 2003 13:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DSwh-0003E6-00 for simple@ietf.org; Wed, 07 May 2003 13:43:11 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19DSwg-0003E2-00 for simple@ietf.org; Wed, 07 May 2003 13:43:10 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h47HhV7H010789; Wed, 7 May 2003 13:43:31 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABI68077; Wed, 7 May 2003 13:52:21 -0400 (EDT) Message-ID: <3EB945C2.4060103@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: Avshalom Houri CC: Simple WG Subject: Re: [Simple] SIMPLE arch document 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, 07 May 2003 13:43:30 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Avshalom, This looks like a good start at identifying what needs to be done, though it is a very ambitious document. Perhaps it needs to be broken up hierarchically somehow. (I haven't thought about how yet, but I fear this doc, when complete could be as big as 3261.) Have you thought about how to move forward with this? To get it all done is probably going to take numerous authors, which is another reason to partition it. There are certainly parts of it that I would be interested in helping with. Thanks, Paul Avshalom Houri wrote: > The SIMPLE charter specifies the following deliverable: > > "An architecture for the implementation of a traditional buddylist- > based instant messaging and presence application with SIP, including > for example new mechanisms for message confirmation delivery, indications > for when a party is in the process of typing a message, secure buddylist > manipulation operations, and the extension of the CPIM presence format > to describe typical IM states." > > We have submitted a (very) initial skeleton document for the above: > > http://www.ietf.org/internet-drafts/draft-houri-simple-arch-00.txt > > I know that the document tries to cover much more then what was intended. > However, in order to continue working on the document we would like to get > some feedback from the group. > > Any input will be appreciated. > > Thanks > Avshalom > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 7 14:27:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11419 for ; Wed, 7 May 2003 14:27:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47IaET10305 for simple-archive@odin.ietf.org; Wed, 7 May 2003 14:36:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47IaE810302 for ; Wed, 7 May 2003 14:36:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11360 for ; Wed, 7 May 2003 14:26:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTel-0003dt-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 14:28:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DTek-0003dq-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 14:28:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Ia7810252; Wed, 7 May 2003 14:36:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47IZl810205 for ; Wed, 7 May 2003 14:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11336 for ; Wed, 7 May 2003 14:26:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DTeJ-0003dF-00 for simple@ietf.org; Wed, 07 May 2003 14:28:15 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19DTeI-0003cy-00 for simple@ietf.org; Wed, 07 May 2003 14:28:14 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h47ISU7H002915; Wed, 7 May 2003 14:28:30 -0400 (EDT) Received: from cisco.com ([161.44.79.220]) by cannon.cisco.com (Mirapoint) with ESMTP id ABI68604; Wed, 7 May 2003 14:37:21 -0400 (EDT) Message-ID: <3EB9504D.30008@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: Avshalom Houri , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052233971.1587.1.camel@dhcp31.dfw.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, 07 May 2003 14:28:29 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm assuming you are questioning the relationship between requests that start out somethin like: REGISTER sip:example.com To: sip:foo@example.com ... and PUBLISH sip:foo@example.com To: sip:foo@example.com ... If so, I think there is some probable precedence of the REGISTER over the SUBSCRIBE. The REGISTER affects the candidate set of contacts for address sip:foo@example.com. It is not routed according to the prior set of registered contacts for that address. OTOH, the PUBLISH, at least in principle, is just an ordinary message, and is routed based on the registered contacts, plus local policy of the proxy/registrar. So, the REGISTER *could* have been installing a contact for the presence server itself. In that case, prior to the register the PUBLISH might have failed, whereas after it might succeed. I don't think the converse is a likely scenario. (That before the publish the register would fail, but after the register would succeed.) I do agree that there are similarities between REGISTER and PUBLISH. I can imagine a system that supports PUBLISH and not REGISTER, and does all routing based on presence, using the contact addresses in presence tuples. That would be an unusual sip system today, though it may be less so in the future. I also agree with Ben that there is plenty of opportunity for local policy to determine what happens here. I expect there will be plenty of systems where the registrar, presence server, and proxy are all bundled together and cooperate via local configuration. Paul Ben Campbell wrote: > I think that is entirely a question of local policy. There is no > protocol requirement for the two operations to be linked in any way, but > a given service provider might choose to do so. > > If you _do_ link them, you are making assumptions about a relationship > between the device doing the publishing and the device doing the > registering that may or may not exist. > > On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: > >>In a system that has both a registrar and a presence server what should be >>the relationships between >>REGISTER and PUBLISH? >> >>* Should a REGISTER make the user on-line even though PUBLISH was not sent >>yet? >>* Should PUBLISH be considered as a login to the system as REGISTER? >> >>To some extent it seems that PUBLISH and REGISTER have a similar >>functionality but one is for the registrar >>while the other is for the presence server. >> >>Avshalom >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 7 17:33:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18630 for ; Wed, 7 May 2003 17:33:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47Lgga27060 for simple-archive@odin.ietf.org; Wed, 7 May 2003 17:42:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Lgg827057 for ; Wed, 7 May 2003 17:42:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18613 for ; Wed, 7 May 2003 17:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DWZ8-00051d-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 17:35:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DWZ8-00051a-00 for simple-web-archive@ietf.org; Wed, 07 May 2003 17:35:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47LgY827034; Wed, 7 May 2003 17:42:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47LdD826897 for ; Wed, 7 May 2003 17:39:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18534 for ; Wed, 7 May 2003 17:29:35 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DWVm-0004zw-00 for simple@ietf.org; Wed, 07 May 2003 17:31:38 -0400 Received: from imo-m06.mx.aol.com ([64.12.136.161]) by ietf-mx with esmtp (Exim 4.12) id 19DWVm-0004za-00 for simple@ietf.org; Wed, 07 May 2003 17:31:38 -0400 Received: from AndrewAllen007@aol.com by imo-m06.mx.aol.com (mail_out_v34.22.) id 7.191.1955622e (15874); Wed, 7 May 2003 17:31:25 -0400 (EDT) Received: from aol.com (mow-m09.webmail.aol.com [64.12.184.137]) by air-id07.mx.aol.com (v93.12) with ESMTP id MAILINID71-3e023eb97b2d8f; Wed, 07 May 2003 17:31:25 -0400 To: hgs@cs.columbia.edu, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: [Simple] [SIMPLE]Comment on draft-schulzrinne-simple-rpids-01 MIME-Version: 1.0 Message-ID: <0C6DA182.46DE6D7B.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 07 May 2003 17:31:25 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h47LgY827034 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47Lgg827057 Content-Transfer-Encoding: 8bit > > While the current list seems to cover what we spend much of our time on during the day it does not include something we all spend a quarter to a third of each day doing – sleeping. > > I propose that “Sleeping” be added to the list as one of the standardized Category indications in the next version of this draft. Noted. > > I observe in current presence Applications that I often see user text added such as “ZZzzzzzz” or even “dreams of bis” etc so it seems commonly useful to indicate to others the sleep state. Obviously a sleeping person only wants to be awoken in a genuine emergency can’t wait situation. > > Many mobile phones include alarm clocks and the sleeping state could be derived automatically when the alarm is set as could the until element (to the time of wakeup). Transition out of this status could also be triggered by the wake up alarm event itself. Frequent international travelers would find such an indication very useful in avoiding those unwanted wakeups because of time zone differences with the office etc. > > I think the sleeping state is quite different from busy as your boss may consider that you are never too busy to talk to him – however waking you up is another thing entirely. Does the powernap count :-)? [AA] If only getting a powernap was as easy as setting the alarm on your mobile to 15 minutes ahead! With Caller Prefs I think we can make sure it counts! ....and here is an embeded or alternatively externally referenced illustration of the powernap for those who want pictures in their presence docs! http://www.geocities.com/gabimori/b_22.html :-) > > Andrew > > _______________________________________________ > 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 mailnull@www1.ietf.org Thu May 8 05:15:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17111 for ; Thu, 8 May 2003 05:15:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h489P1a25414 for simple-archive@odin.ietf.org; Thu, 8 May 2003 05:25:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h489P1825409 for ; Thu, 8 May 2003 05:25:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17099 for ; Thu, 8 May 2003 05:15:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DhWZ-0001Wy-00 for simple-web-archive@ietf.org; Thu, 08 May 2003 05:17:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DhWY-0001Wv-00 for simple-web-archive@ietf.org; Thu, 08 May 2003 05:17:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h489O8825350; Thu, 8 May 2003 05:24:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h489N3825213 for ; Thu, 8 May 2003 05:23:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17017 for ; Thu, 8 May 2003 05:13:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DhUe-0001VN-00 for simple@ietf.org; Thu, 08 May 2003 05:15:13 -0400 Received: from [164.164.94.98] (helo=sonim-india.com) by ietf-mx with esmtp (Exim 4.12) id 19DhUd-0001VH-00 for simple@ietf.org; Thu, 08 May 2003 05:15:11 -0400 Received: (from root@localhost) by sonim-india.com (8.11.6/8.11.6) id h489FeV11074 for ; Thu, 8 May 2003 14:45:40 +0530 Received: from boxer (boxer.sonim-india.com [192.168.2.88]) by sonim-india.com (8.11.6/8.11.6) with SMTP id h489FdJ10901; Thu, 8 May 2003 14:45:39 +0530 From: "Vishal Verma" To: "Avshalom Houri" Cc: "Simple WG" Subject: RE: [Simple] SIMPLE arch document Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3EB945C2.4060103@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-AntiVirus: Scanned for Viruses at sonim communications (india) pvt. ltd. Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 8 May 2003 14:50:43 +0530 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi , I am looking into figure 1. of this document .Few things I could not understand why user agent to REGISTRAR interface is missing ? user agents interact with REGISTRAR using REGISTER method, right ? why user agent to presnece server interface is missing ? presence server will be reporting remote user status to user agent,isnt it ? regards, vishal -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of Paul Kyzivat Sent: Wednesday, May 07, 2003 11:14 PM To: Avshalom Houri Cc: Simple WG Subject: Re: [Simple] SIMPLE arch document Avshalom, This looks like a good start at identifying what needs to be done, though it is a very ambitious document. Perhaps it needs to be broken up hierarchically somehow. (I haven't thought about how yet, but I fear this doc, when complete could be as big as 3261.) Have you thought about how to move forward with this? To get it all done is probably going to take numerous authors, which is another reason to partition it. There are certainly parts of it that I would be interested in helping with. Thanks, Paul Avshalom Houri wrote: > The SIMPLE charter specifies the following deliverable: > > "An architecture for the implementation of a traditional buddylist- > based instant messaging and presence application with SIP, including > for example new mechanisms for message confirmation delivery, indications > for when a party is in the process of typing a message, secure buddylist > manipulation operations, and the extension of the CPIM presence format > to describe typical IM states." > > We have submitted a (very) initial skeleton document for the above: > > http://www.ietf.org/internet-drafts/draft-houri-simple-arch-00.txt > > I know that the document tries to cover much more then what was intended. > However, in order to continue working on the document we would like to get > some feedback from the group. > > Any input will be appreciated. > > Thanks > Avshalom > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 8 05:28:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17575 for ; Thu, 8 May 2003 05:28:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h489cDj27281 for simple-archive@odin.ietf.org; Thu, 8 May 2003 05:38:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h489cD827278 for ; Thu, 8 May 2003 05:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17526 for ; Thu, 8 May 2003 05:28:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DhjK-0001fy-00 for simple-web-archive@ietf.org; Thu, 08 May 2003 05:30:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DhjK-0001fv-00 for simple-web-archive@ietf.org; Thu, 08 May 2003 05:30:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h489c6827245; Thu, 8 May 2003 05:38:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h489YO826169 for ; Thu, 8 May 2003 05:34:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17431 for ; Thu, 8 May 2003 05:24:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dhfe-0001eS-00 for simple@ietf.org; Thu, 08 May 2003 05:26:34 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19Dhfd-0001e3-00 for simple@ietf.org; Thu, 08 May 2003 05:26:33 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by hoemail1.firewall.lucent.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h489Quo23595 for ; Thu, 8 May 2003 05:26:56 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 May 2003 10:26:54 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00877AE52@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Adam Roach , "'Michael Hammer'" Cc: "'Drage, Keith (Keith)'" , simple@ietf.org Subject: RE: [Simple] WGLC: draft-ietf-simple-event-list-01.txt 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, 8 May 2003 10:26:52 +0100 So if I understand Adam's response on this one. He understands what he wrote, and therefore it must be OK for everyone else, even if they have to jump through hoops to do so. Strikes me that it might be easier to change it so mere mortals dont have to decode it. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com] > Sent: 29 April 2003 05:31 > To: 'Michael Hammer'; Adam Roach > Cc: 'Drage, Keith (Keith)'; simple@ietf.org > Subject: RE: [Simple] WGLC: draft-ietf-simple-event-list-01.txt > > > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > > > RFC 2119 is attempting to add strength and remove ambiguity > > to the existing plain English word. I find it confusing when > > "must" doesn't always mean "must". That is to Clintonesque for me. > ... > > Otherwise, I am always left wondering if a MUST was inadvertently > > left as must. Without consistent usage of words, writing clear > > requirements documents is nearly impossible. > > Okay, well, the hints for this case are: > > a) The section under discussion is an example, and > b) The section has a rather rambling disclaimer > pointing out in unambiguous terms that it, in its > entirety, is completely non-normative. > > Further, the statement under discussion is taking > a normative statement of the form "A MUST do Y", > and substituting the values from the example scenario > into A and Y. Even if it is interpreted by someone > who can't pick up on the treble-clue of "this is > lowercase," "this is in an example," and "this section > is clearly marked as non-normative," there is no harm > to be done, as it merely restates a normative clause > from elsewhere in the document. > > /a > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 8 11:26:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26520 for ; Thu, 8 May 2003 11:26:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48FZXP21498 for simple-archive@odin.ietf.org; Thu, 8 May 2003 11:35:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48FZX821495 for ; Thu, 8 May 2003 11:35:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26514 for ; Thu, 8 May 2003 11:25:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DnJ1-0003Ww-00 for simple-web-archive@ietf.org; Thu, 08 May 2003 11:27:35 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19DnJ0-0003Ws-00 for simple-web-archive@ietf.org; Thu, 08 May 2003 11:27:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48FZQ821480; Thu, 8 May 2003 11:35:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48FWn821316 for ; Thu, 8 May 2003 11:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26456 for ; Thu, 8 May 2003 11:22:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DnGN-0003Vt-00 for simple@ietf.org; Thu, 08 May 2003 11:24:51 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19DnGM-0003Vm-00 for simple@ietf.org; Thu, 08 May 2003 11:24:50 -0400 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 h48FP9901047 for ; Thu, 8 May 2003 10:25:09 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1052407412.919.60.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.3 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] INTERIM MEETING attendance query Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 08 May 2003 10:23:32 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit If you are going to be attending the SIMPLE interim meeting in person, please send Mary Barnes (mbarnes@nortelnetworks.com) a private note so that she can ensure the facilities are scaled properly. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 9 09:27:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15158 for ; Fri, 9 May 2003 09:27:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49DbMB06553 for simple-archive@odin.ietf.org; Fri, 9 May 2003 09:37:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49DbM806550 for ; Fri, 9 May 2003 09:37:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15152 for ; Fri, 9 May 2003 09:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E7vk-0004HZ-00 for simple-web-archive@ietf.org; Fri, 09 May 2003 09:28:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19E7vj-0004HW-00 for simple-web-archive@ietf.org; Fri, 09 May 2003 09:28:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49DbE806385; Fri, 9 May 2003 09:37:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49DaH806192 for ; Fri, 9 May 2003 09:36:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15117 for ; Fri, 9 May 2003 09:25:49 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E7uh-0004HD-00 for simple@ietf.org; Fri, 09 May 2003 09:27:51 -0400 Received: from imo-m03.mx.aol.com ([64.12.136.6]) by ietf-mx with esmtp (Exim 4.12) id 19E7ug-0004Gy-00 for simple@ietf.org; Fri, 09 May 2003 09:27:50 -0400 Received: from AndrewAllen007@aol.com by imo-m03.mx.aol.com (mail_out_v34.22.) id l.ba.3e2c3688 (15874); Fri, 9 May 2003 09:28:13 -0400 (EDT) Received: from aol.com (mow-m25.webmail.aol.com [64.12.137.2]) by air-id07.mx.aol.com (v93.12) with ESMTP id MAILINID71-3e023ebbacec2a4; Fri, 09 May 2003 09:28:12 -0400 To: simple@ietf.org Cc: AndrewAllen007@aol.com MIME-Version: 1.0 Message-ID: <484805AC.4C1A5C26.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 Subject: [Simple] Comments on draft-ietf-simple-event-list-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: Fri, 09 May 2003 09:28:12 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h49DbE806385 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h49DbM806550 Content-Transfer-Encoding: 8bit Adam et all I have some comments regarding draft-ietf-simple-event-list-02. First issue is whether consideration has been given to the possibility of loops being set up by lists containing other lists that ultimately reference back to the original list either unintentionally or as a malicious attack. This would seem to be a particular problem if the lists are in different domains with the potential for subscribe requests to be continually generated. Different domains also makes these loops impossible to detect at list creation time. For example three lists are created; A, B and C all in different domains with B having A as a member. A is then modified to also contain C and C is also modified to contain B as a member: W----->C(B)----->B(A)----->A(C)-- ^ | | | ------------------------- If I understand the RLS subscription procedure correctly a watcher (W) subscription to C causes C to send a SUBSCRIBE request to B which causes B to send a SUBSCRIBE request to A since B should not cache the state of subscriptions to A for different watchers (7.2 Risks of Improper Aggregation) as the authorization policy and presence data returned for each watcher may be different. Doesn’t this in turn cause A to send a SUBSCRIBE request to C causing C to send a SUBSCRIBE request to B and so on in a loop? It seems that C needs to be able to detect that the SUBSCRIBE from A is related to the original SUBSCRIBE from watcher W and hence not generate a new SUBSCRIBE to B and probably reject the subscription from A. Currently I don’t see anything in the current document or in the Subscribe request from an RLS that identifies the original watcher or the original subscribe; which it seems would be needed to prevent such loops from occurring. Is this a genuine problem or am I misunderstanding something about the mechanism? If it is a problem then it seems we need some discussion on this and a solution. One possibility might be to include a SIP Frag containing the dialog of the original watcher subscription in SUBSCRIBE requests from the RLS and have the RLS check each SUBSCRIBE to see if it has an existing identical dialog. Second comment is that IMHO the text in 5.4 Instance Attributes does not seem to indicate what is shown in the example regarding the use of the Instance Attribute in the first full state Notify that is returned by an RLS before the results have been received for the resource that is in another domain. The text in 5.4: “Each resource element contains one or more instance elements. These instance elements are used to represent a single notifier for the resource. For event packages that allow forking, multiple virtual subscriptions may exist for a given resource. Multiple virtual subscriptions are represented as multiple instance elements in the corresponding resource element. For subscriptions in which forking does not occur, at most one instance will be present for a given resource.” My interpretation of this text is that the one or more indicates that an instance element should always be present for each resource element. However the example shows that this is not the case in the Notify in step 3 (No instance element for resource ed@example.net). IMHO some clarification is necessary here. regards Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 9 16:31:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00847 for ; Fri, 9 May 2003 16:31:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49KfLG11029 for simple-archive@odin.ietf.org; Fri, 9 May 2003 16:41:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49KfL811025 for ; Fri, 9 May 2003 16:41:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00813 for ; Fri, 9 May 2003 16:30:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEXu-0007DW-00 for simple-web-archive@ietf.org; Fri, 09 May 2003 16:32:46 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EEXt-0007DS-00 for simple-web-archive@ietf.org; Fri, 09 May 2003 16:32:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49KfD811014; Fri, 9 May 2003 16:41:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Ke5810907 for ; Fri, 9 May 2003 16:40:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00759 for ; Fri, 9 May 2003 16:29:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEWg-0007DH-00 for simple@ietf.org; Fri, 09 May 2003 16:31:30 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19EEWg-0007Cw-00 for simple@ietf.org; Fri, 09 May 2003 16:31:30 -0400 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 h49KVv925413 for ; Fri, 9 May 2003 15:31:57 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1052512202.1818.30.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Draft Agenda: Interim 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: 09 May 2003 15:30:02 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Here is a proposed agenda to start working from. Requests for modification/additions are welcome, but weigh the request carefully against taking time away from these topics. RjS ------------------------------------------------------- Thursday May 29 0900-1130 Message Sessions 1130-1300 Lunch 1300-1430 Message Sessions 1430-1600 What is a Tuple 1600-1800 RPIDs Friday May 30 0900-1130 Publish 1130-1300 Lunch 1300-1400 Publish 1400-1600 Data Manipulation _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon May 12 07:25:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08624 for ; Mon, 12 May 2003 07:25:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CAoal17324 for simple-archive@odin.ietf.org; Mon, 12 May 2003 06:50:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAoaB17321 for ; Mon, 12 May 2003 06:50:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08602 for ; Mon, 12 May 2003 07:24:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FBRy-0006wN-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 07:26:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FBRx-0006wJ-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 07:26:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAoVB17312; Mon, 12 May 2003 06:50:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAnjB17225 for ; Mon, 12 May 2003 06:49:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08518; Mon, 12 May 2003 07:23:44 -0400 (EDT) Message-Id: <200305121123.HAA08518@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-filter-reqs-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: Mon, 12 May 2003 07:23:43 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Filtering of Watcher Information Author(s) : K. Kiss et al. Filename : draft-ietf-simple-winfo-filter-reqs-00.txt Pages : 9 Date : 2003-5-9 This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher infomation notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.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 "get draft-ietf-simple-winfo-filter-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-9124017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-filter-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-9124017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon May 12 10:49:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17333 for ; Mon, 12 May 2003 10:49:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CEFIq01803 for simple-archive@odin.ietf.org; Mon, 12 May 2003 10:15:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CEFIB01800 for ; Mon, 12 May 2003 10:15:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17317 for ; Mon, 12 May 2003 10:49:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FEdz-000147-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 10:51:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FEdz-000144-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 10:51:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CEFAB01787; Mon, 12 May 2003 10:15:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CEE8B01657 for ; Mon, 12 May 2003 10:14:08 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17204; Mon, 12 May 2003 10:48:03 -0400 (EDT) Message-Id: <200305121448.KAA17204@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: simple@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-winfo-filter-reqs-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: Mon, 12 May 2003 10:48:03 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Requirements for Filtering of Watcher Information Author(s) : K. Kiss et al. Filename : draft-ietf-simple-winfo-filter-reqs-00.txt Pages : 9 Date : 2003-5-9 This document defines a set of structured requirements whereby a watcher information subscriber (client) may select specific information to be received in the watcher infomation notification sent by the notifier (server). The purpose is to limit the content so that only essential information is delivered by the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.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 "get draft-ietf-simple-winfo-filter-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-9124017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-winfo-filter-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-9124017.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon May 12 13:10:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24346 for ; Mon, 12 May 2003 13:10:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CGaWj13004 for simple-archive@odin.ietf.org; Mon, 12 May 2003 12:36:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CGaWB13001 for ; Mon, 12 May 2003 12:36:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24337 for ; Mon, 12 May 2003 13:10:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FGqc-0002og-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 13:12:23 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FGqc-0002od-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 13:12:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CGaJB12989; Mon, 12 May 2003 12:36:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CGZ5B12960 for ; Mon, 12 May 2003 12:35:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24269 for ; Mon, 12 May 2003 13:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FGpE-0002o8-00 for simple@ietf.org; Mon, 12 May 2003 13:10:56 -0400 Received: from web41510.mail.yahoo.com ([66.218.93.93]) by ietf-mx with smtp (Exim 4.12) id 19FGpD-0002nq-00 for simple@ietf.org; Mon, 12 May 2003 13:10:55 -0400 Message-ID: <20030512171128.97628.qmail@web41510.mail.yahoo.com> Received: from [131.107.3.70] by web41510.mail.yahoo.com via HTTP; Mon, 12 May 2003 10:11:28 PDT From: Sean Olson To: krisztian.kiss@nokia.com, eva-maria.leppanen@nokia.com, hisham.khartabil@nokia.com Cc: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Simple] draft-ietf-simple-winfo-filter-reqs-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: Mon, 12 May 2003 10:11:28 -0700 (PDT) I question the usefulness of the following requirement: 3.4.4 Duration of Subscription The client MUST be able to indicate to the server to include only those watchers in the notifications which are subscribed for a duration higher than (less than) a specific amount of seconds. This seems like a mechanism with a different requirement lurking inside. Are you looking for watchers that are near expiration? What is the scenario you have in mind? /sean __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Mon May 12 14:52:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27691 for ; Mon, 12 May 2003 14:52:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CIIMo20573 for simple-archive@odin.ietf.org; Mon, 12 May 2003 14:18:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CIIMB20570 for ; Mon, 12 May 2003 14:18:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27672 for ; Mon, 12 May 2003 14:52:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FIR8-0003SC-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 14:54:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FIR8-0003S9-00 for simple-web-archive@ietf.org; Mon, 12 May 2003 14:54:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CIIEB20554; Mon, 12 May 2003 14:18:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CIHBB20520 for ; Mon, 12 May 2003 14:17:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27640 for ; Mon, 12 May 2003 14:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FIPz-0003Rl-00 for simple@ietf.org; Mon, 12 May 2003 14:52:59 -0400 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 19FIPy-0003Rh-00 for simple@ietf.org; Mon, 12 May 2003 14:52:58 -0400 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 h4CIrS6o006556; Mon, 12 May 2003 14:53:29 -0400 (EDT) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 May 2003 13:53:28 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3A64799@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Andrew Allen , simple@ietf.org Subject: RE: [Simple] Comments on draft-ietf-simple-event-list-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CIHBB20521 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 12 May 2003 13:53:25 -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4CIIEB20554 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4CIIMB20570 Content-Transfer-Encoding: 8bit Andrew Allen writes: > Currently I don’t see anything in the current document or in > the Subscribe request from an RLS that identifies the > original watcher or the original subscribe; which it seems > would be needed to prevent such loops from occurring. > > Is this a genuine problem or am I misunderstanding something > about the mechanism? > > If it is a problem then it seems we need some discussion on > this and a solution. One possibility might be to include a > SIP Frag containing the dialog of the original watcher > subscription in SUBSCRIBE requests from the RLS and have the > RLS check each SUBSCRIBE to see if it has an existing > identical dialog. This document explicitly points out in several places that the back-end subscriptions may or may not be SIP. We can't put a SIP-specific mechanism in place to address them. The issue of infinite recursion does deserve a mention in the document, and will be added to the security section. Solutions for the general case will be left to implementors. Solutions for the case in which SIP is used on the back end will be described in the forthcoming informative document that discusses implementation of event list servers with SIP back-end subscriptions. > Second comment is that IMHO the text in 5.4 Instance > Attributes does not seem to indicate what is shown in the > example regarding the use of the Instance Attribute in the > first full state Notify that is returned by an RLS before the > results have been received for the resource that is in > another domain. The text in 5.4: > > "Each resource element contains one or more instance elements. These > instance elements are used to represent a single notifier for the > resource. For event packages that allow forking, multiple virtual > subscriptions may exist for a given resource. Multiple virtual > subscriptions are represented as multiple instance elements in the > corresponding resource element. For subscriptions in which forking > does not occur, at most one instance will be present for a given > resource." > > My interpretation of this text is that the one or more > indicates that an instance element should always be present > for each resource element. However the example shows that > this is not the case in the Notify in step 3 (No instance > element for resource ed@example.net). IMHO some clarification > is necessary here. You are correct. The introductory sentence in that paragraph should say "zero or more", not "one or more". Thanks for catching the inconsistency. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Tue May 13 12:28:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19175 for ; Tue, 13 May 2003 12:28:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DFsSH05915 for simple-archive@odin.ietf.org; Tue, 13 May 2003 11:54:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DFsSB05912 for ; Tue, 13 May 2003 11:54:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19156 for ; Tue, 13 May 2003 12:27:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fcey-0005hj-00 for simple-web-archive@ietf.org; Tue, 13 May 2003 12:29:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Fcey-0005hf-00 for simple-web-archive@ietf.org; Tue, 13 May 2003 12:29:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DFsLB05903; Tue, 13 May 2003 11:54:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DFrZB05852 for ; Tue, 13 May 2003 11:53:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19128 for ; Tue, 13 May 2003 12:26:59 -0400 (EDT) From: krisztian.kiss@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fce7-0005h1-00 for simple@ietf.org; Tue, 13 May 2003 12:28:55 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Fce6-0005gy-00 for simple@ietf.org; Tue, 13 May 2003 12:28:54 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4DGTxD27074 for ; Tue, 13 May 2003 19:29:59 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 May 2003 19:29:59 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 19:29:59 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 13 May 2003 19:29:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: draft-ietf-simple-winfo-filter-reqs-00 Thread-Index: AcMYqYi53fGV4+M7Qai2DjaZ7QbRHgAwQkcg To: , , Cc: X-OriginalArrivalTime: 13 May 2003 16:29:58.0163 (UTC) FILETIME=[E4C2A630:01C3196C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4DFrZB05853 Subject: [Simple] RE: draft-ietf-simple-winfo-filter-reqs-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, 13 May 2003 19:29:57 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Sean, Relevant scenarios could be: - include only watchers who have been subscribed for less than some duration - ask for the most recent watchers - limit how old information is delivered - include only watchers who have been subscribed for higher than some duration - in case of requesting history information of watchers 3.4.x only tries to cover the useful scenarios, if the solution is generic (any kind of expression can be set up), then a generic requirement, like "The client MUST be able to indicate to the server to include in the notifications only those watchers with specific element or attribute values" could also make the job instead of 3.4.x. Regards, Krisztian > -----Original Message----- > From: ext Sean Olson [mailto:seancolson@yahoo.com] > Sent: Monday, May 12, 2003 8:11 PM > To: Kiss Krisztian (NRC/Tampere); Leppanen Eva-Maria (NET/Tampere); > Khartabil Hisham (NMP/Helsinki) > Cc: simple@ietf.org > Subject: draft-ietf-simple-winfo-filter-reqs-00 > > > I question the usefulness of the following > requirement: > > 3.4.4 Duration of Subscription > > The client MUST be able to indicate to > the server to include only those watchers > in the notifications which are subscribed > for a duration higher than (less than) a > specific amount of seconds. > > This seems like a mechanism with a different > requirement lurking inside. Are you looking for > watchers that are near expiration? What is the > scenario you have in mind? > > /sean > > > > > > __________________________________ > Do you Yahoo!? > The New Yahoo! Search - Faster. Easier. Bingo. > http://search.yahoo.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed May 28 04:00:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20250; Wed, 28 May 2003 04:00:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kvq1-0007So-00; Wed, 28 May 2003 03:59:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Kvq0-0007Sj-00; Wed, 28 May 2003 03:59:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S7vJB12440; Wed, 28 May 2003 03:57:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S7uwB12409 for ; Wed, 28 May 2003 03:56:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20154 for ; Wed, 28 May 2003 03:56:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KvmK-0007Rx-00 for simple@ietf.org; Wed, 28 May 2003 03:55:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19KvmK-0007Ru-00 for simple@ietf.org; Wed, 28 May 2003 03:55:20 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4S7usD07537 for ; Wed, 28 May 2003 10:56:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 May 2003 10:56:53 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 28 May 2003 10:56:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7665@esebe019.ntc.nokia.com> Thread-Topic: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMi9Xw8PMgBcxn5Q56wiItpGUAFdQB8hjrA To: , X-OriginalArrivalTime: 28 May 2003 07:56:52.0991 (UTC) FILETIME=[B39070F0:01C324EE] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4S7uwB12410 Subject: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-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: Wed, 28 May 2003 10:56:52 +0300 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4S7vJB12440 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA20250 > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Sunday, May 25, 2003 10:40 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Comments on draft-khartabil-simple-filter-funct-00 > > > Hisham, > > I have some comments regarding > draft-khartabil-simple-filter-funct-00, which also have > potential impact on the format defined in > draft-khartabil-simple-filter-format-00. > > First comment relates to clause 3.3 Subscriber Generating > SUBSCRIBE Request and clause 3.3.3 Changing Filter Criteria > within a Dialog: > > As I stated in my earlier email regarding the requirement > draft I have a concern with the replace semantics of the > filter criteria in the Subscribe. I am concerned that the > filter criteria could become quite large especially if the > watcher has different filter criteria for different > presentities within presence lists. Do we need to have every > refresh subscriptions include all the filter criteria for > every presentity being watching everytime as our goal is > bandwidth efficiency between the watcher and the network? I > think that filter criteria will be modified by watchers a lot > less regularly than the period of refresh subscriptions and > so it is better to have some very small extra overhead when > creating, modifying or deleting the filter than having to > include the filter criteria in every refresh. I think some > similar functionality to the partial drafts may be the way > forward here. As I commented earlier, I share your concern and will look into it before the next version of the I-D is released. > > Next comment is applies to clause 3.3.2 Request-URI vs. > Filter Criteria URI, and clause 4.1 Request-URI vs. Filter > Criteria URI: > > IMO we should indicate in the filter criteria that the URL is > targeted at a particular leaf node of a particular branch of > a tree of resource lists (i.e is a member of a particular sub > list and indicate the path to the resource). Not sure I got your point here, but I can comment that the URI in the filter is not restricted to leaves (presentities), but may also contain list URIs. This is where the RLS comes into play. > I think the > advocated approach of propagating the filter criteria to all > the fanned out subscriptions is going to introduce a number > of security and error case handling issues for example many > of the propagated subscriptions may have a final destination > at the same node resulting in a server getting multiple > duplicates of the same filter for the resource that it owns. > Also other nodes will get filters for resources that they do > not own (shouldn’t this result in some kind of error > indication back to the originator otherwise stale filter > criteria for resources that are no longer reachable will > likely accumulate in the Subscribe requests?). Also I think > we are increasing the potential severity of a DOS attack > because this approach unnecessarily duplicates the filter > criteria for the back end subscriptions creating more > messages with larger message bodies which have to be handled > by the server. Only the filter concenred with the resource where the subscribe is being propagated is included. Section 4.1 says: " If the URI indicated by the filter criteria is for one resource who's URI is one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria for that particular resource are extracted and propagated in the SUBSCRIBE request sent to that resource. (it is possible to have more than one filter criteria in a SUBSCRIBE body, and therefore a filter criteria specific to a resource must be extracted and only that is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where "bob@otherdomain.com" is a resource belonging to that list, and the URI in a filter criteria is "sip:bob@otherdomain.com", the filter criteria specific for Bob are extracted and placed in the body of the SUBSCRIBE sent to "bob@otherdomain.com"." > > > Next comment is I think we should be clear that the filter > criteria only relates to the dialog that is established. If I > create a new subscribe-notify dialog then the filter criteria > for the previous dialog are not affected and do not apply to > the new dialog. I think this point should be clarified in > clause 5.2.1 Request-URI vs. Filter Criteria URI Will clarify. > > Next comment relates to clause 3.3.4 Subscriber Interpreting > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > Requests, and clause 5.4 Handling Abnormal Cases: > > The meaning of 200 and 202 responses to Subscribe requests is > already defined in RFC 3265 and they relate to the state of > the subscription I don’t think we should further extend their > meaning to also include a meaning to the state of the filter > criteria. It seems the server has four basic options: > > 1) It can accept the subscription and also accept the filter > criteria. – 200 OK > 2) It can accept the subscription but ignore all the filter > criteria - 200 OK > 3) It can reject the subscription (which also rejects the > filter criteria) - 4xxx > 4) It can indicate that the subscription has been > understood, and that authorization may or may not have been > granted. - 202 I think the text as it is now is ok. Some implementations of the server might want to examine the filter after responding to the SUBSCRIBE. A 202 in this case is needed. > > I think we need a separate mechanism to indicate the > difference between options 2 and 3. Also the UAC should be > able to indicate whether option 2 is acceptable since option > 2 could result in a large presence document being sent in a > Notify, which may not be acceptable to the UAC. I will remove references to the word "ignore" in the next version. If a server does not like a filter, it rejects it. When it comes to authorisation, the server can examine the filter after its has applied the authorisation policy. I'll clarify that also. > > Maybe we should consider defining filtering as an option-tag > used in Supported or Require headers. If Option 2 is > unacceptable to the UAC then it should use a Require: > Filtering in the subscribe, otherwise it uses Supported: > Filtering and includes a Content-Disposition header > indicating that the use and understanding of the body is > optional. If the server takes option 1 then a Require: > Filtering is included in the response. If option 2 is taken > then no Require: Filtering is in the response. Option 3 would > then be a 420 (if Require was in the Subscribe and the server > does not accept filter criteria) or 415 if the content-type > is not understood or some other appropriate 4xx response if > the problem was the filter itself. I think this complication is unnecessery. Thanks for the comments. Hisham > > I am not convinced that 488 is an appropriate response as > this appears to be currently restricted in RFC 3261 to INVITE > and SDP and the body if present should contain SDP indicating > what SDP would be accepted. I would defer to Jonathan’s > opinion though on whether the usage of 488 as defined in the > draft is acceptable. I think we may need a new response code > for when some aspect of the filter is unacceptable that would > allow indication in the body of the part of the filter that > is a problem so that remedial action can be taken. > > Regards > Andrew > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 28 04:01:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20275 for ; Wed, 28 May 2003 04:01:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4S80l212592 for simple-archive@odin.ietf.org; Wed, 28 May 2003 04:00:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S80lB12589 for ; Wed, 28 May 2003 04:00:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20250; Wed, 28 May 2003 04:00:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kvq1-0007So-00; Wed, 28 May 2003 03:59:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Kvq0-0007Sj-00; Wed, 28 May 2003 03:59:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S7vJB12440; Wed, 28 May 2003 03:57:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S7uwB12409 for ; Wed, 28 May 2003 03:56:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20154 for ; Wed, 28 May 2003 03:56:56 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KvmK-0007Rx-00 for simple@ietf.org; Wed, 28 May 2003 03:55:20 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19KvmK-0007Ru-00 for simple@ietf.org; Wed, 28 May 2003 03:55:20 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4S7usD07537 for ; Wed, 28 May 2003 10:56:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 28 May 2003 10:56:53 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 28 May 2003 10:56:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7665@esebe019.ntc.nokia.com> Thread-Topic: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMi9Xw8PMgBcxn5Q56wiItpGUAFdQB8hjrA To: , X-OriginalArrivalTime: 28 May 2003 07:56:52.0991 (UTC) FILETIME=[B39070F0:01C324EE] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4S7uwB12410 Subject: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-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: Wed, 28 May 2003 10:56:52 +0300 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4S7vJB12440 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4S80lB12589 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Sunday, May 25, 2003 10:40 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Comments on draft-khartabil-simple-filter-funct-00 > > > Hisham, > > I have some comments regarding > draft-khartabil-simple-filter-funct-00, which also have > potential impact on the format defined in > draft-khartabil-simple-filter-format-00. > > First comment relates to clause 3.3 Subscriber Generating > SUBSCRIBE Request and clause 3.3.3 Changing Filter Criteria > within a Dialog: > > As I stated in my earlier email regarding the requirement > draft I have a concern with the replace semantics of the > filter criteria in the Subscribe. I am concerned that the > filter criteria could become quite large especially if the > watcher has different filter criteria for different > presentities within presence lists. Do we need to have every > refresh subscriptions include all the filter criteria for > every presentity being watching everytime as our goal is > bandwidth efficiency between the watcher and the network? I > think that filter criteria will be modified by watchers a lot > less regularly than the period of refresh subscriptions and > so it is better to have some very small extra overhead when > creating, modifying or deleting the filter than having to > include the filter criteria in every refresh. I think some > similar functionality to the partial drafts may be the way > forward here. As I commented earlier, I share your concern and will look into it before the next version of the I-D is released. > > Next comment is applies to clause 3.3.2 Request-URI vs. > Filter Criteria URI, and clause 4.1 Request-URI vs. Filter > Criteria URI: > > IMO we should indicate in the filter criteria that the URL is > targeted at a particular leaf node of a particular branch of > a tree of resource lists (i.e is a member of a particular sub > list and indicate the path to the resource). Not sure I got your point here, but I can comment that the URI in the filter is not restricted to leaves (presentities), but may also contain list URIs. This is where the RLS comes into play. > I think the > advocated approach of propagating the filter criteria to all > the fanned out subscriptions is going to introduce a number > of security and error case handling issues for example many > of the propagated subscriptions may have a final destination > at the same node resulting in a server getting multiple > duplicates of the same filter for the resource that it owns. > Also other nodes will get filters for resources that they do > not own (shouldn’t this result in some kind of error > indication back to the originator otherwise stale filter > criteria for resources that are no longer reachable will > likely accumulate in the Subscribe requests?). Also I think > we are increasing the potential severity of a DOS attack > because this approach unnecessarily duplicates the filter > criteria for the back end subscriptions creating more > messages with larger message bodies which have to be handled > by the server. Only the filter concenred with the resource where the subscribe is being propagated is included. Section 4.1 says: " If the URI indicated by the filter criteria is for one resource who's URI is one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria for that particular resource are extracted and propagated in the SUBSCRIBE request sent to that resource. (it is possible to have more than one filter criteria in a SUBSCRIBE body, and therefore a filter criteria specific to a resource must be extracted and only that is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where "bob@otherdomain.com" is a resource belonging to that list, and the URI in a filter criteria is "sip:bob@otherdomain.com", the filter criteria specific for Bob are extracted and placed in the body of the SUBSCRIBE sent to "bob@otherdomain.com"." > > > Next comment is I think we should be clear that the filter > criteria only relates to the dialog that is established. If I > create a new subscribe-notify dialog then the filter criteria > for the previous dialog are not affected and do not apply to > the new dialog. I think this point should be clarified in > clause 5.2.1 Request-URI vs. Filter Criteria URI Will clarify. > > Next comment relates to clause 3.3.4 Subscriber Interpreting > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > Requests, and clause 5.4 Handling Abnormal Cases: > > The meaning of 200 and 202 responses to Subscribe requests is > already defined in RFC 3265 and they relate to the state of > the subscription I don’t think we should further extend their > meaning to also include a meaning to the state of the filter > criteria. It seems the server has four basic options: > > 1) It can accept the subscription and also accept the filter > criteria. – 200 OK > 2) It can accept the subscription but ignore all the filter > criteria - 200 OK > 3) It can reject the subscription (which also rejects the > filter criteria) - 4xxx > 4) It can indicate that the subscription has been > understood, and that authorization may or may not have been > granted. - 202 I think the text as it is now is ok. Some implementations of the server might want to examine the filter after responding to the SUBSCRIBE. A 202 in this case is needed. > > I think we need a separate mechanism to indicate the > difference between options 2 and 3. Also the UAC should be > able to indicate whether option 2 is acceptable since option > 2 could result in a large presence document being sent in a > Notify, which may not be acceptable to the UAC. I will remove references to the word "ignore" in the next version. If a server does not like a filter, it rejects it. When it comes to authorisation, the server can examine the filter after its has applied the authorisation policy. I'll clarify that also. > > Maybe we should consider defining filtering as an option-tag > used in Supported or Require headers. If Option 2 is > unacceptable to the UAC then it should use a Require: > Filtering in the subscribe, otherwise it uses Supported: > Filtering and includes a Content-Disposition header > indicating that the use and understanding of the body is > optional. If the server takes option 1 then a Require: > Filtering is included in the response. If option 2 is taken > then no Require: Filtering is in the response. Option 3 would > then be a 420 (if Require was in the Subscribe and the server > does not accept filter criteria) or 415 if the content-type > is not understood or some other appropriate 4xx response if > the problem was the filter itself. I think this complication is unnecessery. Thanks for the comments. Hisham > > I am not convinced that 488 is an appropriate response as > this appears to be currently restricted in RFC 3261 to INVITE > and SDP and the body if present should contain SDP indicating > what SDP would be accepted. I would defer to Jonathan’s > opinion though on whether the usage of 488 as defined in the > draft is acceptable. I think we may need a new response code > for when some aspect of the filter is unacceptable that would > allow indication in the body of the part of the filter that > is a problem so that remedial action can be taken. > > Regards > Andrew > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed May 28 11:42:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09064; Wed, 28 May 2003 11:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L334-0004Nk-00; Wed, 28 May 2003 11:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L333-0004Nh-00; Wed, 28 May 2003 11:41:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SFdMB14561; Wed, 28 May 2003 11:39:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SFcPB14486 for ; Wed, 28 May 2003 11:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08913 for ; Wed, 28 May 2003 11:38:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L2yu-0004LG-00 for simple@ietf.org; Wed, 28 May 2003 11:36:48 -0400 Received: from tomts6.bellnexxia.net ([209.226.175.26] helo=tomts6-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19L2yt-0004LD-00 for simple@ietf.org; Wed, 28 May 2003 11:36:47 -0400 Received: from [209.226.175.136] by tomts6-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030528153822.MEAR17633.tomts6-srv.bellnexxia.net@[209.226.175.136]> for ; Wed, 28 May 2003 11:38:22 -0400 From: Colin Young Organization: Bell Canada To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030528153822.MEAR17633.tomts6-srv.bellnexxia.net@[209.226.175.136]> Content-Transfer-Encoding: 7bit Subject: [Simple] Congestion Control Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 28 May 2003 11:38:22 -0400 Content-Transfer-Encoding: 7bit Hi, RFC 3428 says (section 8, page 8), "At the time of this writing, there is no mechanism for a UAC to gain such knowledge outside of trivial network architectures, or networks that are wholly controlled by a single administrative domain. But if a mechanism for ensuring congestion-control at each hop is created in the future, MESSAGE clients can relax the size limit without requiring a change to this specification. The authors expect that such a mechanism or mechanism will be created in the near future." I was just wondering if anyone has heard of any progress being made on this issue. Thanks, Colin Young colin.young@bellnexxia.net _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 28 11:43:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09089 for ; Wed, 28 May 2003 11:43:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SFgi614761 for simple-archive@odin.ietf.org; Wed, 28 May 2003 11:42:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SFgiB14758 for ; Wed, 28 May 2003 11:42:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09064; Wed, 28 May 2003 11:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L334-0004Nk-00; Wed, 28 May 2003 11:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L333-0004Nh-00; Wed, 28 May 2003 11:41:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SFdMB14561; Wed, 28 May 2003 11:39:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SFcPB14486 for ; Wed, 28 May 2003 11:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08913 for ; Wed, 28 May 2003 11:38:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L2yu-0004LG-00 for simple@ietf.org; Wed, 28 May 2003 11:36:48 -0400 Received: from tomts6.bellnexxia.net ([209.226.175.26] helo=tomts6-srv.bellnexxia.net) by ietf-mx with esmtp (Exim 4.12) id 19L2yt-0004LD-00 for simple@ietf.org; Wed, 28 May 2003 11:36:47 -0400 Received: from [209.226.175.136] by tomts6-srv.bellnexxia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030528153822.MEAR17633.tomts6-srv.bellnexxia.net@[209.226.175.136]> for ; Wed, 28 May 2003 11:38:22 -0400 From: Colin Young Organization: Bell Canada To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20030528153822.MEAR17633.tomts6-srv.bellnexxia.net@[209.226.175.136]> Content-Transfer-Encoding: 7bit Subject: [Simple] Congestion Control Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 28 May 2003 11:38:22 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, RFC 3428 says (section 8, page 8), "At the time of this writing, there is no mechanism for a UAC to gain such knowledge outside of trivial network architectures, or networks that are wholly controlled by a single administrative domain. But if a mechanism for ensuring congestion-control at each hop is created in the future, MESSAGE clients can relax the size limit without requiring a change to this specification. The authors expect that such a mechanism or mechanism will be created in the near future." I was just wondering if anyone has heard of any progress being made on this issue. Thanks, Colin Young colin.young@bellnexxia.net _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed May 28 14:59: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 OAA16603; Wed, 28 May 2003 14:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L67y-0006Gz-00; Wed, 28 May 2003 14:58:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L67y-0006Gu-00; Wed, 28 May 2003 14:58:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIuYB29613; Wed, 28 May 2003 14:56:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIrHB29524 for ; Wed, 28 May 2003 14:53:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16394 for ; Wed, 28 May 2003 14:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L61P-0006E3-00 for simple@ietf.org; Wed, 28 May 2003 14:51:35 -0400 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 19L61O-0006Di-00 for simple@ietf.org; Wed, 28 May 2003 14:51:34 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4SIqb6n008621 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 28 May 2003 13:52:38 -0500 From: "Dean Willis" To: "'Colin Young'" , Subject: RE: [Simple] Congestion Control Message-ID: <003f01c3254a$4324d200$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030528153822.MEAR17633.tomts6-srv.bellnexxia.net@[209.226.175.136]> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SIrIB29525 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 28 May 2003 13:52:17 -0500 Content-Transfer-Encoding: 8bit Colin asked: > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On > Behalf Of Colin Young > Sent: Wednesday, May 28, 2003 10:38 AM > To: simple@ietf.org > Subject: [Simple] Congestion Control > > > Hi, > > RFC 3428 says (section 8, page 8), > > "At the time of this writing, there is no mechanism for a UAC > to gain such knowledge outside of trivial network > architectures, or networks that are wholly controlled by a > single administrative domain. But if a mechanism for > ensuring congestion-control at each hop is created in the > future, MESSAGE clients can relax the size limit without > requiring a change to this specification. The authors expect > that such a mechanism or mechanism will be created in the > near future." > > I was just wondering if anyone has heard of any progress > being made on this issue. The latest is: http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-01.txt And http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-02 .txt My thinking is that we agreed at the last IETF meeting that we couldn't agreee on what congestion was or what it might mean to be "safe" from it, so we're basically not working on it right now. Have some ideas? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 28 15:00:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16660 for ; Wed, 28 May 2003 15:00:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4SJ05Z29836 for simple-archive@odin.ietf.org; Wed, 28 May 2003 15:00:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SJ05B29833 for ; Wed, 28 May 2003 15:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16603; Wed, 28 May 2003 14:59:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L67y-0006Gz-00; Wed, 28 May 2003 14:58:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19L67y-0006Gu-00; Wed, 28 May 2003 14:58:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIuYB29613; Wed, 28 May 2003 14:56:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4SIrHB29524 for ; Wed, 28 May 2003 14:53:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16394 for ; Wed, 28 May 2003 14:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19L61P-0006E3-00 for simple@ietf.org; Wed, 28 May 2003 14:51:35 -0400 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 19L61O-0006Di-00 for simple@ietf.org; Wed, 28 May 2003 14:51:34 -0400 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id h4SIqb6n008621 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 28 May 2003 13:52:38 -0500 From: "Dean Willis" To: "'Colin Young'" , Subject: RE: [Simple] Congestion Control Message-ID: <003f01c3254a$4324d200$ee036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030528153822.MEAR17633.tomts6-srv.bellnexxia.net@[209.226.175.136]> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4SIrIB29525 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 28 May 2003 13:52:17 -0500 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Colin asked: > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On > Behalf Of Colin Young > Sent: Wednesday, May 28, 2003 10:38 AM > To: simple@ietf.org > Subject: [Simple] Congestion Control > > > Hi, > > RFC 3428 says (section 8, page 8), > > "At the time of this writing, there is no mechanism for a UAC > to gain such knowledge outside of trivial network > architectures, or networks that are wholly controlled by a > single administrative domain. But if a mechanism for > ensuring congestion-control at each hop is created in the > future, MESSAGE clients can relax the size limit without > requiring a change to this specification. The authors expect > that such a mechanism or mechanism will be created in the > near future." > > I was just wondering if anyone has heard of any progress > being made on this issue. The latest is: http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-01.txt And http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-02 .txt My thinking is that we agreed at the last IETF meeting that we couldn't agreee on what congestion was or what it might mean to be "safe" from it, so we're basically not working on it right now. Have some ideas? -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed May 28 20: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 UAA01370; Wed, 28 May 2003 20:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBcZ-0001gL-00; Wed, 28 May 2003 20:50:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LBcY-0001gI-00; Wed, 28 May 2003 20:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T0mXB26931; Wed, 28 May 2003 20:48:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T0ldB26894 for ; Wed, 28 May 2003 20:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01336 for ; Wed, 28 May 2003 20:47:36 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBYN-0001f6-00 for simple@ietf.org; Wed, 28 May 2003 20:45:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19LBYM-0001f3-00 for simple@ietf.org; Wed, 28 May 2003 20:45:58 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4T0lYW08075 for ; Thu, 29 May 2003 03:47:34 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 May 2003 03:47:34 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 29 May 2003 03:47:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Congestion Control Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945294@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Congestion Control Thread-Index: AcMlSu+oiYLsTj9HR9+f8ykWQBrphgALzG5A To: , , X-OriginalArrivalTime: 29 May 2003 00:47:34.0612 (UTC) FILETIME=[E4C97940:01C3257B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4T0ldB26895 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 29 May 2003 03:47:34 +0300 Content-Transfer-Encoding: 8bit Inline. > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28 May, 2003 21:52 > To: 'Colin Young'; simple@ietf.org > Subject: RE: [Simple] Congestion Control > > > > Colin asked: > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On > > Behalf Of Colin Young > > Sent: Wednesday, May 28, 2003 10:38 AM > > To: simple@ietf.org > > Subject: [Simple] Congestion Control > > > > > > Hi, > > > > RFC 3428 says (section 8, page 8), > > > > "At the time of this writing, there is no mechanism for a UAC > > to gain such knowledge outside of trivial network > > architectures, or networks that are wholly controlled by a > > single administrative domain. But if a mechanism for > > ensuring congestion-control at each hop is created in the > > future, MESSAGE clients can relax the size limit without > > requiring a change to this specification. The authors expect > > that such a mechanism or mechanism will be created in the > > near future." > > > > I was just wondering if anyone has heard of any progress > > being made on this issue. > > The latest is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-01.txt > And > http://www.ietf.org/internet-drafts/draft-khartabil-sip-conge > stionsafe-ci-02 > .txt > > My thinking is that we agreed at the last IETF meeting that > we couldn't > agreee on what congestion was or what it might mean to be > "safe" from it, so > we're basically not working on it right now. This probably was the general feeling in the meeting, but perhaps we weren't addressing the right issue there. As I remember the events that lead to MESSAGE having the size restriction in the first place, it was more due to a bug (or was it a feature?) of the SIP spec than IMs being universally congestion safe. I thought all we needed to do in congestsafe to correct this was, really, to have a way of telling proxies not to send the MESSAGE over UDP, no matter what. So what if we drop the safety portion of congestion safe, and focus on ensuring congestion-controlled transport gets used at each hop instead? Cheers, Aki > Have some ideas? > > -- > 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 From mailnull@www1.ietf.org Wed May 28 20:52:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01391 for ; Wed, 28 May 2003 20:52:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T0pxP27017 for simple-archive@odin.ietf.org; Wed, 28 May 2003 20:51:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T0pxB27014 for ; Wed, 28 May 2003 20:51:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01370; Wed, 28 May 2003 20:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBcZ-0001gL-00; Wed, 28 May 2003 20:50:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LBcY-0001gI-00; Wed, 28 May 2003 20:50:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T0mXB26931; Wed, 28 May 2003 20:48:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T0ldB26894 for ; Wed, 28 May 2003 20:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01336 for ; Wed, 28 May 2003 20:47:36 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBYN-0001f6-00 for simple@ietf.org; Wed, 28 May 2003 20:45:59 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19LBYM-0001f3-00 for simple@ietf.org; Wed, 28 May 2003 20:45:58 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4T0lYW08075 for ; Thu, 29 May 2003 03:47:34 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 29 May 2003 03:47:34 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 29 May 2003 03:47:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Congestion Control Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD901945294@esebe013.ntc.nokia.com> Thread-Topic: [Simple] Congestion Control Thread-Index: AcMlSu+oiYLsTj9HR9+f8ykWQBrphgALzG5A To: , , X-OriginalArrivalTime: 29 May 2003 00:47:34.0612 (UTC) FILETIME=[E4C97940:01C3257B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4T0ldB26895 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 29 May 2003 03:47:34 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Inline. > -----Original Message----- > From: ext Dean Willis [mailto:dean.willis@softarmor.com] > Sent: 28 May, 2003 21:52 > To: 'Colin Young'; simple@ietf.org > Subject: RE: [Simple] Congestion Control > > > > Colin asked: > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On > > Behalf Of Colin Young > > Sent: Wednesday, May 28, 2003 10:38 AM > > To: simple@ietf.org > > Subject: [Simple] Congestion Control > > > > > > Hi, > > > > RFC 3428 says (section 8, page 8), > > > > "At the time of this writing, there is no mechanism for a UAC > > to gain such knowledge outside of trivial network > > architectures, or networks that are wholly controlled by a > > single administrative domain. But if a mechanism for > > ensuring congestion-control at each hop is created in the > > future, MESSAGE clients can relax the size limit without > > requiring a change to this specification. The authors expect > > that such a mechanism or mechanism will be created in the > > near future." > > > > I was just wondering if anyone has heard of any progress > > being made on this issue. > > The latest is: > > http://www.ietf.org/internet-drafts/draft-ietf-sip-congestsafe-01.txt > And > http://www.ietf.org/internet-drafts/draft-khartabil-sip-conge > stionsafe-ci-02 > .txt > > My thinking is that we agreed at the last IETF meeting that > we couldn't > agreee on what congestion was or what it might mean to be > "safe" from it, so > we're basically not working on it right now. This probably was the general feeling in the meeting, but perhaps we weren't addressing the right issue there. As I remember the events that lead to MESSAGE having the size restriction in the first place, it was more due to a bug (or was it a feature?) of the SIP spec than IMs being universally congestion safe. I thought all we needed to do in congestsafe to correct this was, really, to have a way of telling proxies not to send the MESSAGE over UDP, no matter what. So what if we drop the safety portion of congestion safe, and focus on ensuring congestion-controlled transport gets used at each hop instead? Cheers, Aki > Have some ideas? > > -- > 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 From simple-admin@ietf.org Wed May 28 21:14:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01835; Wed, 28 May 2003 21:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LByO-0001lp-00; Wed, 28 May 2003 21:12:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LByN-0001lm-00; Wed, 28 May 2003 21:12:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T1BAB28797; Wed, 28 May 2003 21:11:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T1AxB28779 for ; Wed, 28 May 2003 21:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01758 for ; Wed, 28 May 2003 21:10:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBux-0001l1-00 for simple@ietf.org; Wed, 28 May 2003 21:09:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19LBuw-0001ky-00 for simple@ietf.org; Wed, 28 May 2003 21:09:18 -0400 Received: from [127.0.0.1] (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h4T1Ag8w002400; Wed, 28 May 2003 20:10:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Jonathan Rosenberg Cc: Simple WG Content-Type: text/plain Message-Id: <1054150182.2350.75.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on xcap drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 28 May 2003 20:10:37 -0500 Content-Transfer-Encoding: 7bit I like the overall approach a lot. Here are my comments, the vast majority of which are nits. Introduction: (nit) You conflate server storage of presence lists with list subscriptions. It may be useful to store such lists on servers simply to facilitate list mobility, even without list subscriptions. Conversely, although we have not defined it, there may be some use for ad-hoc list subscriptions, where the contents of the list are _not_ stored on a server, but rather carried in the subscription request. I think the xcap URIs actually fit the definition for URLs. Should we not simply call them URLs? Are global and user trees normative, or simply examples? 6.4 Do we really want clients doing this rather than using the event package? If so, should there be guidelines on minimum poling intervals? 6.6 It seems like MUST be text/plain is a little strong. Cannot an application define elements where other types would be more appropriate? 6.8 If I get an XML document containing only one element, is that by nature guaranteed to be schema compliant? 7: Use of 404 for service not found and user not found does not give much granularity. draft-rosenberg-simple-xcap-list-usage-00.txt: Introduction: (nit) Language of the form "users subscribe to their presence list" implies a single list, where a user may indeed have many lists. I agree that policy specification should be kept separate. 5: It seems like there are some uniqueness requirements for list URIs that should be addressed here. 8. The security policies here do not seem to allow the concept of shared lists. We may eventually want ACLs for a list. I can accept that this might currently be out of scope, but it may be useful in a future extension. draft-rosenberg-simple-xcap-package-00.txt: (nit) I would s/package/event-package in the document title. I did not realize this was a sip events package until I read the abstract. 2.2 I would rather the r-uri to indicate the doc-component being subscribed to, not the user. What about global data not associated with a user? The semantic should be I subscribe to the piece of information, then the server decides if the user (me) is authorized. The fact the data belongs to my user tree does not change that--it just indicates a high likelyhood that I am authorized. As written, the semantic seems more like I am subscribing to the user, with a filter to determine the doc-component. 2.4 The motivation for choosing high default expiration times ignores the fault-recovery aspect of soft state. Large expiration times increase the time before a client will discover a server failure 2.5. It seems inconsistent to have only the version returned in the first NOTIFY, but the actual changes returned in subsequent ones. It might be worthwile to at least allow a mode where only the new version gets returned in a NOTIFY. This allows a client to invalidate its cache, and only retrieve the new data when it needs it. 4. Are their security considerations around knowing who changed something? For example, if A subscribes to a doc-component, and B changes it, shoud A know B was the culprit? This might indicate a need for signing changes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 28 21:14:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01854 for ; Wed, 28 May 2003 21:14:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T1EWq28940 for simple-archive@odin.ietf.org; Wed, 28 May 2003 21:14:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T1EWB28937 for ; Wed, 28 May 2003 21:14:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01835; Wed, 28 May 2003 21:14:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LByO-0001lp-00; Wed, 28 May 2003 21:12:52 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LByN-0001lm-00; Wed, 28 May 2003 21:12:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T1BAB28797; Wed, 28 May 2003 21:11:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T1AxB28779 for ; Wed, 28 May 2003 21:10:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01758 for ; Wed, 28 May 2003 21:10:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LBux-0001l1-00 for simple@ietf.org; Wed, 28 May 2003 21:09:19 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19LBuw-0001ky-00 for simple@ietf.org; Wed, 28 May 2003 21:09:18 -0400 Received: from [127.0.0.1] (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h4T1Ag8w002400; Wed, 28 May 2003 20:10:43 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Jonathan Rosenberg Cc: Simple WG Content-Type: text/plain Message-Id: <1054150182.2350.75.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Comments on xcap drafts Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 28 May 2003 20:10:37 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I like the overall approach a lot. Here are my comments, the vast majority of which are nits. Introduction: (nit) You conflate server storage of presence lists with list subscriptions. It may be useful to store such lists on servers simply to facilitate list mobility, even without list subscriptions. Conversely, although we have not defined it, there may be some use for ad-hoc list subscriptions, where the contents of the list are _not_ stored on a server, but rather carried in the subscription request. I think the xcap URIs actually fit the definition for URLs. Should we not simply call them URLs? Are global and user trees normative, or simply examples? 6.4 Do we really want clients doing this rather than using the event package? If so, should there be guidelines on minimum poling intervals? 6.6 It seems like MUST be text/plain is a little strong. Cannot an application define elements where other types would be more appropriate? 6.8 If I get an XML document containing only one element, is that by nature guaranteed to be schema compliant? 7: Use of 404 for service not found and user not found does not give much granularity. draft-rosenberg-simple-xcap-list-usage-00.txt: Introduction: (nit) Language of the form "users subscribe to their presence list" implies a single list, where a user may indeed have many lists. I agree that policy specification should be kept separate. 5: It seems like there are some uniqueness requirements for list URIs that should be addressed here. 8. The security policies here do not seem to allow the concept of shared lists. We may eventually want ACLs for a list. I can accept that this might currently be out of scope, but it may be useful in a future extension. draft-rosenberg-simple-xcap-package-00.txt: (nit) I would s/package/event-package in the document title. I did not realize this was a sip events package until I read the abstract. 2.2 I would rather the r-uri to indicate the doc-component being subscribed to, not the user. What about global data not associated with a user? The semantic should be I subscribe to the piece of information, then the server decides if the user (me) is authorized. The fact the data belongs to my user tree does not change that--it just indicates a high likelyhood that I am authorized. As written, the semantic seems more like I am subscribing to the user, with a filter to determine the doc-component. 2.4 The motivation for choosing high default expiration times ignores the fault-recovery aspect of soft state. Large expiration times increase the time before a client will discover a server failure 2.5. It seems inconsistent to have only the version returned in the first NOTIFY, but the actual changes returned in subsequent ones. It might be worthwile to at least allow a mode where only the new version gets returned in a NOTIFY. This allows a client to invalidate its cache, and only retrieve the new data when it needs it. 4. Are their security considerations around knowing who changed something? For example, if A subscribes to a doc-component, and B changes it, shoud A know B was the culprit? This might indicate a need for signing changes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed May 28 22:07:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03056; Wed, 28 May 2003 22:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LCnm-000254-00; Wed, 28 May 2003 22:05:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LCnl-000251-00; Wed, 28 May 2003 22:05:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T24FB31525; Wed, 28 May 2003 22:04:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T23eB31506 for ; Wed, 28 May 2003 22:03:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02970 for ; Wed, 28 May 2003 22:03:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LCju-000247-00 for simple@ietf.org; Wed, 28 May 2003 22:01:58 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19LCjt-000244-00 for simple@ietf.org; Wed, 28 May 2003 22:01:58 -0400 Received: from [127.0.0.1] (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h4T23K8w005632; Wed, 28 May 2003 21:03:20 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Paul Kyzivat Cc: Simple WG , Robert Sparks , Jonathan Rosenberg , Adam Roach In-Reply-To: <3ED3A034.9020205@cisco.com> References: <3ED3A034.9020205@cisco.com> Content-Type: text/plain Message-Id: <1054173642.1309.21.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-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: 28 May 2003 21:00:42 -0500 Content-Transfer-Encoding: 7bit Sorry for not responding sooner--I had some email technical difficulties over the weekend. Comments inline. On Tue, 2003-05-27 at 12:28, Paul Kyzivat wrote: > Now that this draft is being publicly discussed, I will add these > comments to the discussion. > > Paul > > -------- Original Message -------- > Subject: Re: Draft Submission > Date: Thu, 22 May 2003 21:02:39 -0400 > From: Paul Kyzivat > To: Ben Campbell > CC: internet-drafts@ietf.org , Jon Peterson > , Robert Sparks , > Jonathan Rosenberg > References: <1053631482.1201.10.camel@dhcp31.dfw.dynamicsoft.com> > > Ben Campbell wrote: > > Please accept the attached as an Internet Draft submission. This draft > > is a work item of the SIMPLE work group. > > This is looking really good. I can almost believe it is close to being > baked!!! Thanks! > > I can't resist commenting to some extent: > > 5.1) I'm uncomfortable with overloading the format list to describe both > envelopes and contents. It then leads to hacks like the special casing > of message/cpim as first entry in section 9.4. > > Can't we just say that the formats listed in the m-line are only for top > level types, which typically would only be message/cpim or maybe some > other envelope type? Then define a new attribute in which to enumerate > types that may be contained in the envelope. E.g., > > m=message 49232 msrp/tcp message/cpim > a=content: text/plain text/html > I don't have strong feelings on this. I was merely following practices I have seen elsewhere for compound formats. If we were to separate envelopes from content formats, I would tend to do the reverse; putting leaf formats in the format list, and envelope specifications in an attribute. > 5.3) You say the address in the c-line and the port in the m-line are > irrelevant. This isn't quite true. Minimally, a value of zero in the > port field is relevant to rejecting the media stream altogether. > > In addition, ignoring the c-line has a consequence that might be > significant. It means there is no way to "blackhole" a media stream. > There are interesting call flows where blackholing is important. > > One possibility is to define a blackhole msrp url, such as > msrp://0.0.0.0. The disadvantage of that is the node doing the > blackholing needs to understand m=message is special in order to do it. > In other cases it can be done naively without regard to media type. So > another alternative would be to say we ignore the c-line as long as it > isn't c=0.0.0.0. This is analogous to the hack for a zero port. I think I prefer keeping the "0" semantics in the port field, and fixing the wording. > > 6.4) I found it very confusing that "credentials" and "challenge" aren't > defined here, but are instead defined much later. In between, references > are made to the non-terminals defined in that later part. I would prefer > to see all the syntax in one place. I see pros and cons either way. It probably makes sense to consolidate all the abnf. > > 6.5) I am trying to remember why we have imposed no ordering of > messages, via TR-ID or otherwise. Ordering is a valuable thing for IM. > Hmm. I would think the transport will enforce ordering, now that we have no shared connections. Maybe we need to say something about relays maintaining order. > Also in this section you talk about timing out responses. But you don't > ever say what should happen if a response arrives which fails to match > any outstanding request. For timeouts to be useful, I guess late > responses must be ignored, and that implies that bogus responses must > also be ignored because they can't be distinguished. OK > > 6.6.1) In step 5 when an answerer is participating as a visitor, you say > the c-line is copied unmodified from the offer to the answer. This seems > unnecessary since the c-line is ignored in any case. And it can't always > be done. If the c-line is global rather than local to the media stream, > and there are multiple media streams, then it can't be copied. > OK > You also say the format list must be the same or a subset. You don't say > if ordering must be preserved. Of course it doesn't matter if ordering > is irrelevant. I think the only order specific behavior is * as last and > message/cpim as first. But I wonder if order ought to express > preference, as it does with codecs? I order should express preference, which would imply maintaining order. > > 6.6.3.1) you say "in SIP it *would* send a BYE...". This isn't the only > alternative. (The media stream might be dropped by setting the port to > zero.) So I think you need to say "in SIP it *could* send a BYE...". Good point. > > In next paragraph there are words missing: "This request MUST be sent > [to the] host...". > > 6.6.4) In first line, s/mention/mentioned/ > > 6.7.1) Item 1: you reference "the well-known port for MSRP relays" while > earlier you say there is no default port. > > The description of what an MSRP relay does also mentions its well-known > port. Oops. > > Further, the description of BIND doesn't say anything about refreshing a > BIND. It ought to be mentioned somewhere. One special behavior is > probably required on refresh of bind: it must return the same session > url as it did previously. > Agreed, > 6.7.4) Item 6: I'm thinking it would be good to permit the visiting > relay to adjust the expiration time (down) before relaying it on. > Hmm. I had been thinking about whether it could reduce the time on the response, which clearly doesn't work. But I think your suggestion works. > Then in item 7 there are some words missing: "Relay all subsequent [?] > arriving...". I don't know if this should say "messages", "SEND and > VISIT messages", or what. I think I meant "messages." But on reflection that is probably overbroard. > > 6.9) in last paragraph you say sending a new request identical to the > previous request. In addition to adding the CAuth header, doesn't the > Tr-ID header need a new value? > You are correct. > 6.12.4) The def of nonce says: "This string SHOULD > take the form of base64 or hexadecimal data". If it is base64 or hex > then it needs to be decoded before being used in the MD5 algorithm. But > there is nothing here to say how to tell base64 from hex from other. > I had thought the operations would be on the encoded data, rather than on decoded data. > 7) The examples are using atlanta.com and biloxi.com. I thought there > was a rule that examples all had to use *.example.com. > RFC3261 uses atlanta.com, etc. But I can change it if we need to. > 7.1) Item 2: missing a CR after "both" > > Item 8: missing a CR before "Hi" > > 9.3) s/encryption on for each/encryption for each/ > > ----- > > That's all I can find to note. > > Look'n Good, > Paul > > > > > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 28 22:08:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03071 for ; Wed, 28 May 2003 22:08:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T27el32482 for simple-archive@odin.ietf.org; Wed, 28 May 2003 22:07:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T27eB32479 for ; Wed, 28 May 2003 22:07:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03056; Wed, 28 May 2003 22:07:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LCnm-000254-00; Wed, 28 May 2003 22:05:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LCnl-000251-00; Wed, 28 May 2003 22:05:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T24FB31525; Wed, 28 May 2003 22:04:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T23eB31506 for ; Wed, 28 May 2003 22:03:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02970 for ; Wed, 28 May 2003 22:03:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LCju-000247-00 for simple@ietf.org; Wed, 28 May 2003 22:01:58 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19LCjt-000244-00 for simple@ietf.org; Wed, 28 May 2003 22:01:58 -0400 Received: from [127.0.0.1] (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h4T23K8w005632; Wed, 28 May 2003 21:03:20 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) From: Ben Campbell To: Paul Kyzivat Cc: Simple WG , Robert Sparks , Jonathan Rosenberg , Adam Roach In-Reply-To: <3ED3A034.9020205@cisco.com> References: <3ED3A034.9020205@cisco.com> Content-Type: text/plain Message-Id: <1054173642.1309.21.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-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: 28 May 2003 21:00:42 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry for not responding sooner--I had some email technical difficulties over the weekend. Comments inline. On Tue, 2003-05-27 at 12:28, Paul Kyzivat wrote: > Now that this draft is being publicly discussed, I will add these > comments to the discussion. > > Paul > > -------- Original Message -------- > Subject: Re: Draft Submission > Date: Thu, 22 May 2003 21:02:39 -0400 > From: Paul Kyzivat > To: Ben Campbell > CC: internet-drafts@ietf.org , Jon Peterson > , Robert Sparks , > Jonathan Rosenberg > References: <1053631482.1201.10.camel@dhcp31.dfw.dynamicsoft.com> > > Ben Campbell wrote: > > Please accept the attached as an Internet Draft submission. This draft > > is a work item of the SIMPLE work group. > > This is looking really good. I can almost believe it is close to being > baked!!! Thanks! > > I can't resist commenting to some extent: > > 5.1) I'm uncomfortable with overloading the format list to describe both > envelopes and contents. It then leads to hacks like the special casing > of message/cpim as first entry in section 9.4. > > Can't we just say that the formats listed in the m-line are only for top > level types, which typically would only be message/cpim or maybe some > other envelope type? Then define a new attribute in which to enumerate > types that may be contained in the envelope. E.g., > > m=message 49232 msrp/tcp message/cpim > a=content: text/plain text/html > I don't have strong feelings on this. I was merely following practices I have seen elsewhere for compound formats. If we were to separate envelopes from content formats, I would tend to do the reverse; putting leaf formats in the format list, and envelope specifications in an attribute. > 5.3) You say the address in the c-line and the port in the m-line are > irrelevant. This isn't quite true. Minimally, a value of zero in the > port field is relevant to rejecting the media stream altogether. > > In addition, ignoring the c-line has a consequence that might be > significant. It means there is no way to "blackhole" a media stream. > There are interesting call flows where blackholing is important. > > One possibility is to define a blackhole msrp url, such as > msrp://0.0.0.0. The disadvantage of that is the node doing the > blackholing needs to understand m=message is special in order to do it. > In other cases it can be done naively without regard to media type. So > another alternative would be to say we ignore the c-line as long as it > isn't c=0.0.0.0. This is analogous to the hack for a zero port. I think I prefer keeping the "0" semantics in the port field, and fixing the wording. > > 6.4) I found it very confusing that "credentials" and "challenge" aren't > defined here, but are instead defined much later. In between, references > are made to the non-terminals defined in that later part. I would prefer > to see all the syntax in one place. I see pros and cons either way. It probably makes sense to consolidate all the abnf. > > 6.5) I am trying to remember why we have imposed no ordering of > messages, via TR-ID or otherwise. Ordering is a valuable thing for IM. > Hmm. I would think the transport will enforce ordering, now that we have no shared connections. Maybe we need to say something about relays maintaining order. > Also in this section you talk about timing out responses. But you don't > ever say what should happen if a response arrives which fails to match > any outstanding request. For timeouts to be useful, I guess late > responses must be ignored, and that implies that bogus responses must > also be ignored because they can't be distinguished. OK > > 6.6.1) In step 5 when an answerer is participating as a visitor, you say > the c-line is copied unmodified from the offer to the answer. This seems > unnecessary since the c-line is ignored in any case. And it can't always > be done. If the c-line is global rather than local to the media stream, > and there are multiple media streams, then it can't be copied. > OK > You also say the format list must be the same or a subset. You don't say > if ordering must be preserved. Of course it doesn't matter if ordering > is irrelevant. I think the only order specific behavior is * as last and > message/cpim as first. But I wonder if order ought to express > preference, as it does with codecs? I order should express preference, which would imply maintaining order. > > 6.6.3.1) you say "in SIP it *would* send a BYE...". This isn't the only > alternative. (The media stream might be dropped by setting the port to > zero.) So I think you need to say "in SIP it *could* send a BYE...". Good point. > > In next paragraph there are words missing: "This request MUST be sent > [to the] host...". > > 6.6.4) In first line, s/mention/mentioned/ > > 6.7.1) Item 1: you reference "the well-known port for MSRP relays" while > earlier you say there is no default port. > > The description of what an MSRP relay does also mentions its well-known > port. Oops. > > Further, the description of BIND doesn't say anything about refreshing a > BIND. It ought to be mentioned somewhere. One special behavior is > probably required on refresh of bind: it must return the same session > url as it did previously. > Agreed, > 6.7.4) Item 6: I'm thinking it would be good to permit the visiting > relay to adjust the expiration time (down) before relaying it on. > Hmm. I had been thinking about whether it could reduce the time on the response, which clearly doesn't work. But I think your suggestion works. > Then in item 7 there are some words missing: "Relay all subsequent [?] > arriving...". I don't know if this should say "messages", "SEND and > VISIT messages", or what. I think I meant "messages." But on reflection that is probably overbroard. > > 6.9) in last paragraph you say sending a new request identical to the > previous request. In addition to adding the CAuth header, doesn't the > Tr-ID header need a new value? > You are correct. > 6.12.4) The def of nonce says: "This string SHOULD > take the form of base64 or hexadecimal data". If it is base64 or hex > then it needs to be decoded before being used in the MD5 algorithm. But > there is nothing here to say how to tell base64 from hex from other. > I had thought the operations would be on the encoded data, rather than on decoded data. > 7) The examples are using atlanta.com and biloxi.com. I thought there > was a rule that examples all had to use *.example.com. > RFC3261 uses atlanta.com, etc. But I can change it if we need to. > 7.1) Item 2: missing a CR after "both" > > Item 8: missing a CR before "Hi" > > 9.3) s/encryption on for each/encryption for each/ > > ----- > > That's all I can find to note. > > Look'n Good, > Paul > > > > > > > > > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed May 28 23:21:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04712; Wed, 28 May 2003 23:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LDxP-0002WS-00; Wed, 28 May 2003 23:19:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LDxO-0002WP-00; Wed, 28 May 2003 23:19:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3IGB03996; Wed, 28 May 2003 23:18:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3H5B03958 for ; Wed, 28 May 2003 23:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04652 for ; Wed, 28 May 2003 23:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LDt1-0002Uw-00 for simple@ietf.org; Wed, 28 May 2003 23:15:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19LDt0-0002Uh-00 for simple@ietf.org; Wed, 28 May 2003 23:15:26 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4T3GPFV008745; Wed, 28 May 2003 23:16:26 -0400 (EDT) Received: from cisco.com (rtp-vpn2-809.cisco.com [10.82.243.41]) by cannon.cisco.com (Mirapoint) with ESMTP id ABJ91321; Wed, 28 May 2003 23:25:15 -0400 (EDT) Message-ID: <3ED57B83.4020909@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: Simple WG , Robert Sparks , Jonathan Rosenberg , Adam Roach References: <3ED3A034.9020205@cisco.com> <1054173642.1309.21.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-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: Wed, 28 May 2003 23:16:19 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>Can't we just say that the formats listed in the m-line are only for top >>level types, which typically would only be message/cpim or maybe some >>other envelope type? Then define a new attribute in which to enumerate >>types that may be contained in the envelope. E.g., >> >> m=message 49232 msrp/tcp message/cpim >> a=content: text/plain text/html > > I don't have strong feelings on this. I was merely following practices I > have seen elsewhere for compound formats. If we were to separate > envelopes from content formats, I would tend to do the reverse; putting > leaf formats in the format list, and envelope specifications in an > attribute. I've had real problems with the ambiguity. Here it makes a difference, because unless you distinguish envelopes from contents there is no way to say the content must be within an envelope. I don't know if there are reasons why we can't/shouldn't do this, but it seems like a good idea to me. My reason for suggesting that the envelope be in the m-line is because in some sense that is all the MSRP protocol cares about. The leaves are of interest to whatever opens the envelope. But some discussion, and a beer, might convince me of the error in my thinking. >>5.3) You say the address in the c-line and the port in the m-line are >>irrelevant. This isn't quite true. Minimally, a value of zero in the >>port field is relevant to rejecting the media stream altogether. >> >>In addition, ignoring the c-line has a consequence that might be >>significant. It means there is no way to "blackhole" a media stream. >>There are interesting call flows where blackholing is important. >> >>One possibility is to define a blackhole msrp url, such as >>msrp://0.0.0.0. The disadvantage of that is the node doing the >>blackholing needs to understand m=message is special in order to do it. >>In other cases it can be done naively without regard to media type. So >>another alternative would be to say we ignore the c-line as long as it >>isn't c=0.0.0.0. This is analogous to the hack for a zero port. > > I think I prefer keeping the "0" semantics in the port field, and fixing > the wording. That is only half of the issue. That means you can at least refuse an m=message media stream. But that still leaves the separate issue of how to blackhole one. I think I prefer c=0.0.0.0 for that. >>6.5) I am trying to remember why we have imposed no ordering of >>messages, via TR-ID or otherwise. Ordering is a valuable thing for IM. > > Hmm. I would think the transport will enforce ordering, now that we have > no shared connections. Maybe we need to say something about relays > maintaining order. That may be sufficient now. But maybe we need to think more about ordering. I'm wondering what happens when we build an IM conference mixer. In that case order of arrival at the mixer may be a poor way of determining order. But maybe this is a rathole right now. >>You also say the format list must be the same or a subset. You don't say >>if ordering must be preserved. Of course it doesn't matter if ordering >>is irrelevant. I think the only order specific behavior is * as last and >>message/cpim as first. But I wonder if order ought to express >>preference, as it does with codecs? > > I order should express preference, which would imply maintaining order. It makes sense. Just need to say something about it. >>6.12.4) The def of nonce says: "This string SHOULD >>take the form of base64 or hexadecimal data". If it is base64 or hex >>then it needs to be decoded before being used in the MD5 algorithm. But >>there is nothing here to say how to tell base64 from hex from other. > > I had thought the operations would be on the encoded data, rather than > on decoded data. I'm no crypto expert, but I would think that a bad thing. The nonce is supposed to introduce randomness. But if it always takes the form of a sequence of bytes that are all drawn from the characters used to represent hex or radix64 then the string is distinctly less random than it ideally should be. And if the only goal is to avoid conflicting with ", then it would be simpler to just say the string can't include ". It makes sense that this should encode a random bitstring, which would need to be encoded in hex or radix64 to be transmitted. But then it would need to be decoded before use, which requires that it be possible to figure out how to decode it. Radix64 can't always be distinguished from hex by inspection, since every hex string is a valid radix64 string. >>7) The examples are using atlanta.com and biloxi.com. I thought there >>was a rule that examples all had to use *.example.com. > > RFC3261 uses atlanta.com, etc. But I can change it if we need to. I don't care, but I thought I had seen people whacked for not using example.com. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Wed May 28 23:22:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04747 for ; Wed, 28 May 2003 23:22:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4T3Lci04127 for simple-archive@odin.ietf.org; Wed, 28 May 2003 23:21:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3LcB04124 for ; Wed, 28 May 2003 23:21:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04712; Wed, 28 May 2003 23:21:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LDxP-0002WS-00; Wed, 28 May 2003 23:19:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LDxO-0002WP-00; Wed, 28 May 2003 23:19:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3IGB03996; Wed, 28 May 2003 23:18:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4T3H5B03958 for ; Wed, 28 May 2003 23:17:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04652 for ; Wed, 28 May 2003 23:17:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LDt1-0002Uw-00 for simple@ietf.org; Wed, 28 May 2003 23:15:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19LDt0-0002Uh-00 for simple@ietf.org; Wed, 28 May 2003 23:15:26 -0400 Received: from cannon.cisco.com (IDENT:mirapoint@cannon.cisco.com [161.44.118.24]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4T3GPFV008745; Wed, 28 May 2003 23:16:26 -0400 (EDT) Received: from cisco.com (rtp-vpn2-809.cisco.com [10.82.243.41]) by cannon.cisco.com (Mirapoint) with ESMTP id ABJ91321; Wed, 28 May 2003 23:25:15 -0400 (EDT) Message-ID: <3ED57B83.4020909@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: Simple WG , Robert Sparks , Jonathan Rosenberg , Adam Roach References: <3ED3A034.9020205@cisco.com> <1054173642.1309.21.camel@verite.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Comments on draft-ietf-simple-message-sesisons-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: Wed, 28 May 2003 23:16:19 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>Can't we just say that the formats listed in the m-line are only for top >>level types, which typically would only be message/cpim or maybe some >>other envelope type? Then define a new attribute in which to enumerate >>types that may be contained in the envelope. E.g., >> >> m=message 49232 msrp/tcp message/cpim >> a=content: text/plain text/html > > I don't have strong feelings on this. I was merely following practices I > have seen elsewhere for compound formats. If we were to separate > envelopes from content formats, I would tend to do the reverse; putting > leaf formats in the format list, and envelope specifications in an > attribute. I've had real problems with the ambiguity. Here it makes a difference, because unless you distinguish envelopes from contents there is no way to say the content must be within an envelope. I don't know if there are reasons why we can't/shouldn't do this, but it seems like a good idea to me. My reason for suggesting that the envelope be in the m-line is because in some sense that is all the MSRP protocol cares about. The leaves are of interest to whatever opens the envelope. But some discussion, and a beer, might convince me of the error in my thinking. >>5.3) You say the address in the c-line and the port in the m-line are >>irrelevant. This isn't quite true. Minimally, a value of zero in the >>port field is relevant to rejecting the media stream altogether. >> >>In addition, ignoring the c-line has a consequence that might be >>significant. It means there is no way to "blackhole" a media stream. >>There are interesting call flows where blackholing is important. >> >>One possibility is to define a blackhole msrp url, such as >>msrp://0.0.0.0. The disadvantage of that is the node doing the >>blackholing needs to understand m=message is special in order to do it. >>In other cases it can be done naively without regard to media type. So >>another alternative would be to say we ignore the c-line as long as it >>isn't c=0.0.0.0. This is analogous to the hack for a zero port. > > I think I prefer keeping the "0" semantics in the port field, and fixing > the wording. That is only half of the issue. That means you can at least refuse an m=message media stream. But that still leaves the separate issue of how to blackhole one. I think I prefer c=0.0.0.0 for that. >>6.5) I am trying to remember why we have imposed no ordering of >>messages, via TR-ID or otherwise. Ordering is a valuable thing for IM. > > Hmm. I would think the transport will enforce ordering, now that we have > no shared connections. Maybe we need to say something about relays > maintaining order. That may be sufficient now. But maybe we need to think more about ordering. I'm wondering what happens when we build an IM conference mixer. In that case order of arrival at the mixer may be a poor way of determining order. But maybe this is a rathole right now. >>You also say the format list must be the same or a subset. You don't say >>if ordering must be preserved. Of course it doesn't matter if ordering >>is irrelevant. I think the only order specific behavior is * as last and >>message/cpim as first. But I wonder if order ought to express >>preference, as it does with codecs? > > I order should express preference, which would imply maintaining order. It makes sense. Just need to say something about it. >>6.12.4) The def of nonce says: "This string SHOULD >>take the form of base64 or hexadecimal data". If it is base64 or hex >>then it needs to be decoded before being used in the MD5 algorithm. But >>there is nothing here to say how to tell base64 from hex from other. > > I had thought the operations would be on the encoded data, rather than > on decoded data. I'm no crypto expert, but I would think that a bad thing. The nonce is supposed to introduce randomness. But if it always takes the form of a sequence of bytes that are all drawn from the characters used to represent hex or radix64 then the string is distinctly less random than it ideally should be. And if the only goal is to avoid conflicting with ", then it would be simpler to just say the string can't include ". It makes sense that this should encode a random bitstring, which would need to be encoded in hex or radix64 to be transmitted. But then it would need to be decoded before use, which requires that it be possible to figure out how to decode it. Radix64 can't always be distinguished from hex by inspection, since every hex string is a valid radix64 string. >>7) The examples are using atlanta.com and biloxi.com. I thought there >>was a rule that examples all had to use *.example.com. > > RFC3261 uses atlanta.com, etc. But I can change it if we need to. I don't care, but I thought I had seen people whacked for not using example.com. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 08:52:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01496; Thu, 29 May 2003 08:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LMrx-0006oB-00; Thu, 29 May 2003 08:50:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LMrx-0006o8-00; Thu, 29 May 2003 08:50:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCnIB19094; Thu, 29 May 2003 08:49:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCmmB19067 for ; Thu, 29 May 2003 08:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01456 for ; Thu, 29 May 2003 08:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LMoF-0006n7-00 for simple@ietf.org; Thu, 29 May 2003 08:47:07 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LMoE-0006ma-00 for simple@ietf.org; Thu, 29 May 2003 08:47:06 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TCmE625951 for ; Thu, 29 May 2003 07:48:14 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054212493.923.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE Interim begins Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 08:48:13 -0400 Content-Transfer-Encoding: 7bit I think I have given bridge details to all who have requested them. If I've missed someone, please send me an email. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 08:53:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01518 for ; Thu, 29 May 2003 08:53:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TCqdw19225 for simple-archive@odin.ietf.org; Thu, 29 May 2003 08:52:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCqdB19222 for ; Thu, 29 May 2003 08:52:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01496; Thu, 29 May 2003 08:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LMrx-0006oB-00; Thu, 29 May 2003 08:50:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LMrx-0006o8-00; Thu, 29 May 2003 08:50:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCnIB19094; Thu, 29 May 2003 08:49:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TCmmB19067 for ; Thu, 29 May 2003 08:48:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01456 for ; Thu, 29 May 2003 08:48:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LMoF-0006n7-00 for simple@ietf.org; Thu, 29 May 2003 08:47:07 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LMoE-0006ma-00 for simple@ietf.org; Thu, 29 May 2003 08:47:06 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TCmE625951 for ; Thu, 29 May 2003 07:48:14 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054212493.923.2.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] SIMPLE Interim begins Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 08:48:13 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think I have given bridge details to all who have requested them. If I've missed someone, please send me an email. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 09:09:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02089; Thu, 29 May 2003 09:09:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LN8I-0006xC-00; Thu, 29 May 2003 09:07:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LN8H-0006x9-00; Thu, 29 May 2003 09:07:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TD67B19705; Thu, 29 May 2003 09:06:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TD5SB19673 for ; Thu, 29 May 2003 09:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01945 for ; Thu, 29 May 2003 09:05:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LN4M-0006ur-00 for simple@ietf.org; Thu, 29 May 2003 09:03:46 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LN4M-0006um-00 for simple@ietf.org; Thu, 29 May 2003 09:03:46 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TD4s626102 for ; Thu, 29 May 2003 08:04:54 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054213492.936.4.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for the message sessions discussion Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 09:04:52 -0400 Content-Transfer-Encoding: 7bit www.nostrum.com/~ben/message-sessions_simple-interim-meeting.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 09:09:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02145 for ; Thu, 29 May 2003 09:09:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TD9W020763 for simple-archive@odin.ietf.org; Thu, 29 May 2003 09:09:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TD9WB20760 for ; Thu, 29 May 2003 09:09:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02089; Thu, 29 May 2003 09:09:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LN8I-0006xC-00; Thu, 29 May 2003 09:07:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LN8H-0006x9-00; Thu, 29 May 2003 09:07:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TD67B19705; Thu, 29 May 2003 09:06:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TD5SB19673 for ; Thu, 29 May 2003 09:05:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01945 for ; Thu, 29 May 2003 09:05:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LN4M-0006ur-00 for simple@ietf.org; Thu, 29 May 2003 09:03:46 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LN4M-0006um-00 for simple@ietf.org; Thu, 29 May 2003 09:03:46 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TD4s626102 for ; Thu, 29 May 2003 08:04:54 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054213492.936.4.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for the message sessions discussion Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 09:04:52 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit www.nostrum.com/~ben/message-sessions_simple-interim-meeting.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 11:37: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 LAA07580; Thu, 29 May 2003 11:37:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPRd-000086-00; Thu, 29 May 2003 11:35:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LPRd-000083-00; Thu, 29 May 2003 11:35:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFYDB29865; Thu, 29 May 2003 11:34:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFXWB29831 for ; Thu, 29 May 2003 11:33:32 -0400 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 ; Thu, 29 May 2003 11:33:29 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPNg-000064-00 for simple@ietf.org; Thu, 29 May 2003 11:31:52 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19LPNf-00005c-00 for simple@ietf.org; Thu, 29 May 2003 11:31:51 -0400 Received: from AndrewAllen007@aol.com by imo-r07.mx.aol.com (mail_out_v36.3.) id p.181.1bb99eab (16112); Thu, 29 May 2003 11:31:41 -0400 (EDT) Received: from aol.com (mow-d13.webmail.aol.com [205.188.139.129]) by air-id12.mx.aol.com (v93.12) with ESMTP id MAILINID124-3ef03ed627dd38b; Thu, 29 May 2003 11:31:41 2000 To: hisham.khartabil@nokia.com, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <5D3B74FA.1D1F4793.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4TFXWB29832 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 29 May 2003 11:31:41 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4TFYDB29865 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA07580 Hi Hisham, My response is included inline preceded with the usual [AA]. Regards Andrew Subj: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Date: 5/28/2003 2:56:52 AM Eastern Standard Time From: hisham.khartabil@nokia.com To: , Sent from the Internet (Details) > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Sunday, May 25, 2003 10:40 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Comments on draft-khartabil-simple-filter-funct-00 > > Hisham, > > I have some comments regarding > draft-khartabil-simple-filter-funct-00, which also have > potential impact on the format defined in > draft-khartabil-simple-filter-format-00. > > First comment relates to clause 3.3 Subscriber Generating > SUBSCRIBE Request and clause 3.3.3 Changing Filter Criteria > within a Dialog: > > As I stated in my earlier email regarding the requirement > draft I have a concern with the replace semantics of the > filter criteria in the Subscribe. I am concerned that the > filter criteria could become quite large especially if the > watcher has different filter criteria for different > presentities within presence lists. Do we need to have every > refresh subscriptions include all the filter criteria for > every presentity being watching everytime as our goal is > bandwidth efficiency between the watcher and the network? I > think that filter criteria will be modified by watchers a lot > less regularly than the period of refresh subscriptions and > so it is better to have some very small extra overhead when > creating, modifying or deleting the filter than having to > include the filter criteria in every refresh. I think some > similar functionality to the partial drafts may be the way > forward here. As I commented earlier, I share your concern and will look into it before the next version of the I-D is released. [AA] OK > > Next comment is applies to clause 3.3.2 Request-URI vs. > Filter Criteria URI, and clause 4.1 Request-URI vs. Filter > Criteria URI: > > IMO we should indicate in the filter criteria that the URL is > targeted at a particular leaf node of a particular branch of > a tree of resource lists (i.e is a member of a particular sub > list and indicate the path to the resource). Not sure I got your point here, but I can comment that the URI in the filter is not restricted to leaves (presentities), but may also contain list URIs. This is where the RLS comes into play. [AA] see below > I think the > advocated approach of propagating the filter criteria to all > the fanned out subscriptions is going to introduce a number > of security and error case handling issues for example many > of the propagated subscriptions may have a final destination > at the same node resulting in a server getting multiple > duplicates of the same filter for the resource that it owns. > Also other nodes will get filters for resources that they do > not own (shouldn’t this result in some kind of error > indication back to the originator otherwise stale filter > criteria for resources that are no longer reachable will > likely accumulate in the Subscribe requests?). Also I think > we are increasing the potential severity of a DOS attack > because this approach unnecessarily duplicates the filter > criteria for the back end subscriptions creating more > messages with larger message bodies which have to be handled > by the server. Only the filter concenred with the resource where the subscribe is being propagated is included. Section 4.1 says: " If the URI indicated by the filter criteria is for one resource who's URI is one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria for that particular resource are extracted and propagated in the SUBSCRIBE request sent to that resource. (it is possible to have more than one filter criteria in a SUBSCRIBE body, and therefore a filter criteria specific to a resource must be extracted and only that is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where "bob@otherdomain.com" is a resource belonging to that list, and the URI in a filter criteria is "sip:bob@otherdomain.com", the filter criteria specific for Bob are extracted and placed in the body of the SUBSCRIBE sent to "bob@otherdomain.com"." [AA] The text at issue here is in clause 4.1 “If the URI indicated by the filter criteria is for one resource who's URI is NOT one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria are propagated to all the fanned out subscriptions. This is to accommodate the scenario where the subscriber knows that there are sub-lists in the list that the original subscription was sent to, and the subscriber wishes to set a filter criteria for a resource in that sub-list.” [AA] The issue that I am identifying is when the filter criteria corresponds to a resource that is a child of a sub list of the list. For instance 3 lists A, B, and C, each in different domains where A is a child of B and B is a child of C: CàBàA [AA] Now in the subscription to C I want to be able to include filter criteria that is targeted at a particular member of list A (Amember1). In order to target the URI member of A in the subscription to list C we need to specify the path of the URI: C->B->A->Amember1. Maybe Xpath can also be used for this purpose? For the reasons stated I think simply propagating the filter criteria corresponding to a resource unknown to the RLS to every descendent, (as I understand from this text is proposed), is a bad idea. Instead the filter criteria should only be propagated down the specific branch that contains the target. In addition to the issues raised earlier, I think also there may be privacy concerns with broadcasting the filter criteria to other branches of the tree that are possibly in different domains from the target (i.e Do you want your company to know who all your personal contacts are?) > > > Next comment is I think we should be clear that the filter > criteria only relates to the dialog that is established. If I > create a new subscribe-notify dialog then the filter criteria > for the previous dialog are not affected and do not apply to > the new dialog. I think this point should be clarified in > clause 5.2.1 Request-URI vs. Filter Criteria URI Will clarify. [AA] OK > > Next comment relates to clause 3.3.4 Subscriber Interpreting > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > Requests, and clause 5.4 Handling Abnormal Cases: > > The meaning of 200 and 202 responses to Subscribe requests is > already defined in RFC 3265 and they relate to the state of > the subscription I don’t think we should further extend their > meaning to also include a meaning to the state of the filter > criteria. It seems the server has four basic options: > > 1) It can accept the subscription and also accept the filter > criteria. – 200 OK > 2) It can accept the subscription but ignore all the filter > criteria - 200 OK > 3) It can reject the subscription (which also rejects the > filter criteria) - 4xxx > 4) It can indicate that the subscription has been > understood, and that authorization may or may not have been > granted. - 202 I think the text as it is now is ok. Some implementations of the server might want to examine the filter after responding to the SUBSCRIBE. A 202 in this case is needed. [AA] My concern is with extending the meaning of 200 OK and 202 from that stated in RFC 3265. The text of concern is in clause 5.2 “A "200" response indicates that the subscription has been accepted, the user is authorized and the filter is accepted.” AND “A "202" response also indicates that the filter criteria have not been accepted yet.” [AA] IMO even if we go with the approach of rejecting the subscription if the filter criteria is rejected we do not need this text since the RFC 3265 wording still applies – the subscription is either rejected or authorised or pending. If the implementation wants to examine the filter criteria before authorising the subscription then a 202 is appropriate and I think this is covered in 3265 as well. If we choose to always reject the subscription if the filter criteria is not acceptable then all we need to state in the draft is that rejection of the filter criteria means that the subscription must also be rejected as you propose below. > I think we need a separate mechanism to indicate the > difference between options 2 and 3. Also the UAC should be > able to indicate whether option 2 is acceptable since option > 2 could result in a large presence document being sent in a > Notify, which may not be acceptable to the UAC. I will remove references to the word "ignore" in the next version. If a server does not like a filter, it rejects it. When it comes to authorisation, the server can examine the filter after its has applied the authorisation policy. I'll clarify that also. [AA] This is certainly one approach we could take however this means that if I would like to use filtering but I am willing to accept the subscription without filtering then I may have to make two subscription attempts one with and one without filtering. It seems to me that it would be more efficient to use the SIP extension use negotiation capabilities (Supported and Require) for a more efficient and flexible mechanism. This is also along the lines of what is currently proposed in draft-lonnfors-simple-partial-notify where the option is there to indicate whether the use of the extension is required or not. IMO it would make sense to be consistent with subscription state handling for both partial notifications and filtering. > > Maybe we should consider defining filtering as an option-tag > used in Supported or Require headers. If Option 2 is > unacceptable to the UAC then it should use a Require: > Filtering in the subscribe, otherwise it uses Supported: > Filtering and includes a Content-Disposition header > indicating that the use and understanding of the body is > optional. If the server takes option 1 then a Require: > Filtering is included in the response. If option 2 is taken > then no Require: Filtering is in the response. Option 3 would > then be a 420 (if Require was in the Subscribe and the server > does not accept filter criteria) or 415 if the content-type > is not understood or some other appropriate 4xx response if > the problem was the filter itself. I think this complication is unnecessery. [AA] I don’t think this is complicated, just standard SIP extension negotiation as used in extensions such as Preconditions. Thanks for the comments. Hisham > > I am not convinced that 488 is an appropriate response as > this appears to be currently restricted in RFC 3261 to INVITE > and SDP and the body if present should contain SDP indicating > what SDP would be accepted. I would defer to Jonathan’s > opinion though on whether the usage of 488 as defined in the > draft is acceptable. I think we may need a new response code > for when some aspect of the filter is unacceptable that would > allow indication in the body of the part of the filter that > is a problem so that remedial action can be taken. > > Regards > Andrew [AA] Do you have any comment on my 488 applicability comment? I think we need a response code that would allow us to include the problem filter in the body of the response. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 11:38:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07625 for ; Thu, 29 May 2003 11:38:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TFbcN30880 for simple-archive@odin.ietf.org; Thu, 29 May 2003 11:37:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFbcB30877 for ; Thu, 29 May 2003 11:37:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07580; Thu, 29 May 2003 11:37:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPRd-000086-00; Thu, 29 May 2003 11:35:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LPRd-000083-00; Thu, 29 May 2003 11:35:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFYDB29865; Thu, 29 May 2003 11:34:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TFXWB29831 for ; Thu, 29 May 2003 11:33:32 -0400 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 ; Thu, 29 May 2003 11:33:29 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LPNg-000064-00 for simple@ietf.org; Thu, 29 May 2003 11:31:52 -0400 Received: from imo-r07.mx.aol.com ([152.163.225.103]) by ietf-mx with esmtp (Exim 4.12) id 19LPNf-00005c-00 for simple@ietf.org; Thu, 29 May 2003 11:31:51 -0400 Received: from AndrewAllen007@aol.com by imo-r07.mx.aol.com (mail_out_v36.3.) id p.181.1bb99eab (16112); Thu, 29 May 2003 11:31:41 -0400 (EDT) Received: from aol.com (mow-d13.webmail.aol.com [205.188.139.129]) by air-id12.mx.aol.com (v93.12) with ESMTP id MAILINID124-3ef03ed627dd38b; Thu, 29 May 2003 11:31:41 2000 To: hisham.khartabil@nokia.com, simple@ietf.org Cc: AndrewAllen007@aol.com Subject: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 MIME-Version: 1.0 Message-ID: <5D3B74FA.1D1F4793.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=utf-8 X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4TFXWB29832 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 29 May 2003 11:31:41 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4TFYDB29865 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4TFbcB30877 Content-Transfer-Encoding: 8bit Hi Hisham, My response is included inline preceded with the usual [AA]. Regards Andrew Subj: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Date: 5/28/2003 2:56:52 AM Eastern Standard Time From: hisham.khartabil@nokia.com To: , Sent from the Internet (Details) > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Sunday, May 25, 2003 10:40 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Comments on draft-khartabil-simple-filter-funct-00 > > Hisham, > > I have some comments regarding > draft-khartabil-simple-filter-funct-00, which also have > potential impact on the format defined in > draft-khartabil-simple-filter-format-00. > > First comment relates to clause 3.3 Subscriber Generating > SUBSCRIBE Request and clause 3.3.3 Changing Filter Criteria > within a Dialog: > > As I stated in my earlier email regarding the requirement > draft I have a concern with the replace semantics of the > filter criteria in the Subscribe. I am concerned that the > filter criteria could become quite large especially if the > watcher has different filter criteria for different > presentities within presence lists. Do we need to have every > refresh subscriptions include all the filter criteria for > every presentity being watching everytime as our goal is > bandwidth efficiency between the watcher and the network? I > think that filter criteria will be modified by watchers a lot > less regularly than the period of refresh subscriptions and > so it is better to have some very small extra overhead when > creating, modifying or deleting the filter than having to > include the filter criteria in every refresh. I think some > similar functionality to the partial drafts may be the way > forward here. As I commented earlier, I share your concern and will look into it before the next version of the I-D is released. [AA] OK > > Next comment is applies to clause 3.3.2 Request-URI vs. > Filter Criteria URI, and clause 4.1 Request-URI vs. Filter > Criteria URI: > > IMO we should indicate in the filter criteria that the URL is > targeted at a particular leaf node of a particular branch of > a tree of resource lists (i.e is a member of a particular sub > list and indicate the path to the resource). Not sure I got your point here, but I can comment that the URI in the filter is not restricted to leaves (presentities), but may also contain list URIs. This is where the RLS comes into play. [AA] see below > I think the > advocated approach of propagating the filter criteria to all > the fanned out subscriptions is going to introduce a number > of security and error case handling issues for example many > of the propagated subscriptions may have a final destination > at the same node resulting in a server getting multiple > duplicates of the same filter for the resource that it owns. > Also other nodes will get filters for resources that they do > not own (shouldn’t this result in some kind of error > indication back to the originator otherwise stale filter > criteria for resources that are no longer reachable will > likely accumulate in the Subscribe requests?). Also I think > we are increasing the potential severity of a DOS attack > because this approach unnecessarily duplicates the filter > criteria for the back end subscriptions creating more > messages with larger message bodies which have to be handled > by the server. Only the filter concenred with the resource where the subscribe is being propagated is included. Section 4.1 says: " If the URI indicated by the filter criteria is for one resource who's URI is one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria for that particular resource are extracted and propagated in the SUBSCRIBE request sent to that resource. (it is possible to have more than one filter criteria in a SUBSCRIBE body, and therefore a filter criteria specific to a resource must be extracted and only that is propagated. For example, if the Request-URI in a SUBSCRIBE has the value "sip:mybuddies@mydomain.com" where "bob@otherdomain.com" is a resource belonging to that list, and the URI in a filter criteria is "sip:bob@otherdomain.com", the filter criteria specific for Bob are extracted and placed in the body of the SUBSCRIBE sent to "bob@otherdomain.com"." [AA] The text at issue here is in clause 4.1 “If the URI indicated by the filter criteria is for one resource who's URI is NOT one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria are propagated to all the fanned out subscriptions. This is to accommodate the scenario where the subscriber knows that there are sub-lists in the list that the original subscription was sent to, and the subscriber wishes to set a filter criteria for a resource in that sub-list.” [AA] The issue that I am identifying is when the filter criteria corresponds to a resource that is a child of a sub list of the list. For instance 3 lists A, B, and C, each in different domains where A is a child of B and B is a child of C: CàBàA [AA] Now in the subscription to C I want to be able to include filter criteria that is targeted at a particular member of list A (Amember1). In order to target the URI member of A in the subscription to list C we need to specify the path of the URI: C->B->A->Amember1. Maybe Xpath can also be used for this purpose? For the reasons stated I think simply propagating the filter criteria corresponding to a resource unknown to the RLS to every descendent, (as I understand from this text is proposed), is a bad idea. Instead the filter criteria should only be propagated down the specific branch that contains the target. In addition to the issues raised earlier, I think also there may be privacy concerns with broadcasting the filter criteria to other branches of the tree that are possibly in different domains from the target (i.e Do you want your company to know who all your personal contacts are?) > > > Next comment is I think we should be clear that the filter > criteria only relates to the dialog that is established. If I > create a new subscribe-notify dialog then the filter criteria > for the previous dialog are not affected and do not apply to > the new dialog. I think this point should be clarified in > clause 5.2.1 Request-URI vs. Filter Criteria URI Will clarify. [AA] OK > > Next comment relates to clause 3.3.4 Subscriber Interpreting > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > Requests, and clause 5.4 Handling Abnormal Cases: > > The meaning of 200 and 202 responses to Subscribe requests is > already defined in RFC 3265 and they relate to the state of > the subscription I don’t think we should further extend their > meaning to also include a meaning to the state of the filter > criteria. It seems the server has four basic options: > > 1) It can accept the subscription and also accept the filter > criteria. – 200 OK > 2) It can accept the subscription but ignore all the filter > criteria - 200 OK > 3) It can reject the subscription (which also rejects the > filter criteria) - 4xxx > 4) It can indicate that the subscription has been > understood, and that authorization may or may not have been > granted. - 202 I think the text as it is now is ok. Some implementations of the server might want to examine the filter after responding to the SUBSCRIBE. A 202 in this case is needed. [AA] My concern is with extending the meaning of 200 OK and 202 from that stated in RFC 3265. The text of concern is in clause 5.2 “A "200" response indicates that the subscription has been accepted, the user is authorized and the filter is accepted.” AND “A "202" response also indicates that the filter criteria have not been accepted yet.” [AA] IMO even if we go with the approach of rejecting the subscription if the filter criteria is rejected we do not need this text since the RFC 3265 wording still applies – the subscription is either rejected or authorised or pending. If the implementation wants to examine the filter criteria before authorising the subscription then a 202 is appropriate and I think this is covered in 3265 as well. If we choose to always reject the subscription if the filter criteria is not acceptable then all we need to state in the draft is that rejection of the filter criteria means that the subscription must also be rejected as you propose below. > I think we need a separate mechanism to indicate the > difference between options 2 and 3. Also the UAC should be > able to indicate whether option 2 is acceptable since option > 2 could result in a large presence document being sent in a > Notify, which may not be acceptable to the UAC. I will remove references to the word "ignore" in the next version. If a server does not like a filter, it rejects it. When it comes to authorisation, the server can examine the filter after its has applied the authorisation policy. I'll clarify that also. [AA] This is certainly one approach we could take however this means that if I would like to use filtering but I am willing to accept the subscription without filtering then I may have to make two subscription attempts one with and one without filtering. It seems to me that it would be more efficient to use the SIP extension use negotiation capabilities (Supported and Require) for a more efficient and flexible mechanism. This is also along the lines of what is currently proposed in draft-lonnfors-simple-partial-notify where the option is there to indicate whether the use of the extension is required or not. IMO it would make sense to be consistent with subscription state handling for both partial notifications and filtering. > > Maybe we should consider defining filtering as an option-tag > used in Supported or Require headers. If Option 2 is > unacceptable to the UAC then it should use a Require: > Filtering in the subscribe, otherwise it uses Supported: > Filtering and includes a Content-Disposition header > indicating that the use and understanding of the body is > optional. If the server takes option 1 then a Require: > Filtering is included in the response. If option 2 is taken > then no Require: Filtering is in the response. Option 3 would > then be a 420 (if Require was in the Subscribe and the server > does not accept filter criteria) or 415 if the content-type > is not understood or some other appropriate 4xx response if > the problem was the filter itself. I think this complication is unnecessery. [AA] I don’t think this is complicated, just standard SIP extension negotiation as used in extensions such as Preconditions. Thanks for the comments. Hisham > > I am not convinced that 488 is an appropriate response as > this appears to be currently restricted in RFC 3261 to INVITE > and SDP and the body if present should contain SDP indicating > what SDP would be accepted. I would defer to Jonathan’s > opinion though on whether the usage of 488 as defined in the > draft is acceptable. I think we may need a new response code > for when some aspect of the filter is unacceptable that would > allow indication in the body of the part of the filter that > is a problem so that remedial action can be taken. > > Regards > Andrew [AA] Do you have any comment on my 488 applicability comment? I think we need a response code that would allow us to include the problem filter in the body of the response. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 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 MAA09360; Thu, 29 May 2003 12:30:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQGv-0000YR-00; Thu, 29 May 2003 12:28:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LQGu-0000YO-00; Thu, 29 May 2003 12:28:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGRGB02074; Thu, 29 May 2003 12:27:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGQfB02023 for ; Thu, 29 May 2003 12:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09141 for ; Thu, 29 May 2003 12:26:37 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQD6-0000UA-00 for simple@ietf.org; Thu, 29 May 2003 12:25:00 -0400 Received: from imo-r03.mx.aol.com ([152.163.225.99]) by ietf-mx with esmtp (Exim 4.12) id 19LQD6-0000U7-00 for simple@ietf.org; Thu, 29 May 2003 12:25:00 -0400 Received: from AndrewAllen007@aol.com by imo-r03.mx.aol.com (mail_out_v36.3.) id p.75.1209a60e (15898); Thu, 29 May 2003 11:36:21 -0400 (EDT) Received: from aol.com (mow-d19.webmail.aol.com [205.188.139.135]) by air-id09.mx.aol.com (v93.12) with ESMTP id MAILINID91-3e1a3ed628f512d; Thu, 29 May 2003 11:36:21 -0400 To: hisham.khartabil@nokia.com, simple@ietf.org Cc: AndrewAllen007@aol.com MIME-Version: 1.0 Message-ID: <57530560.6774F3CA.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Simple] Comments on draft-khartabil-simple-filter-format-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: Thu, 29 May 2003 11:36:20 -0400 Content-Transfer-Encoding: 8bit Hisham, I currently have just a small comment regarding draft-khartabil-simple-filter-format-00, however I think some of the comments against the requirements and functional drafts may also have a consequentual impact against this draft. I think we need an example of the usage of the added and removed triggers. It is not clear to me how it is envisioned that the syntax works right now. Regards Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 12:31:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09398 for ; Thu, 29 May 2003 12:31:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TGUcs02378 for simple-archive@odin.ietf.org; Thu, 29 May 2003 12:30:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGUcB02375 for ; Thu, 29 May 2003 12:30:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09360; Thu, 29 May 2003 12:30:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQGv-0000YR-00; Thu, 29 May 2003 12:28:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LQGu-0000YO-00; Thu, 29 May 2003 12:28:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGRGB02074; Thu, 29 May 2003 12:27:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TGQfB02023 for ; Thu, 29 May 2003 12:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09141 for ; Thu, 29 May 2003 12:26:37 -0400 (EDT) From: AndrewAllen007@aol.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQD6-0000UA-00 for simple@ietf.org; Thu, 29 May 2003 12:25:00 -0400 Received: from imo-r03.mx.aol.com ([152.163.225.99]) by ietf-mx with esmtp (Exim 4.12) id 19LQD6-0000U7-00 for simple@ietf.org; Thu, 29 May 2003 12:25:00 -0400 Received: from AndrewAllen007@aol.com by imo-r03.mx.aol.com (mail_out_v36.3.) id p.75.1209a60e (15898); Thu, 29 May 2003 11:36:21 -0400 (EDT) Received: from aol.com (mow-d19.webmail.aol.com [205.188.139.135]) by air-id09.mx.aol.com (v93.12) with ESMTP id MAILINID91-3e1a3ed628f512d; Thu, 29 May 2003 11:36:21 -0400 To: hisham.khartabil@nokia.com, simple@ietf.org Cc: AndrewAllen007@aol.com MIME-Version: 1.0 Message-ID: <57530560.6774F3CA.2E6F5200@aol.com> X-Mailer: Atlas Mailer 2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Simple] Comments on draft-khartabil-simple-filter-format-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: Thu, 29 May 2003 11:36:20 -0400 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hisham, I currently have just a small comment regarding draft-khartabil-simple-filter-format-00, however I think some of the comments against the requirements and functional drafts may also have a consequentual impact against this draft. I think we need an example of the usage of the added and removed triggers. It is not clear to me how it is envisioned that the syntax works right now. Regards Andrew _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 13:12:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10648; Thu, 29 May 2003 13:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQvS-0000nt-00; Thu, 29 May 2003 13:10:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LQvR-0000nq-00; Thu, 29 May 2003 13:10:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TH9BB05910; Thu, 29 May 2003 13:09:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TH8QB05890 for ; Thu, 29 May 2003 13:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10526 for ; Thu, 29 May 2003 13:08:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQrU-0000mA-00 for simple@ietf.org; Thu, 29 May 2003 13:06:44 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LQrT-0000lw-00 for simple@ietf.org; Thu, 29 May 2003 13:06:43 -0400 Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4TH7jZE003484; Thu, 29 May 2003 13:07:45 -0400 (EDT) Message-ID: <3ED63E5C.9050403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org Subject: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <2038BCC78B1AD641891A0D1AE133DBB7FE7665@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7665@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, 29 May 2003 13:07:40 -0400 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >> As I stated in my earlier email regarding the requirement draft I >> have a concern with the replace semantics of the filter criteria >> in the Subscribe. I am concerned that the filter criteria could >> become quite large especially if the watcher has different filter >> criteria for different presentities within presence lists. Do we >> need to have every refresh subscriptions include all the filter >> criteria for every presentity being watching everytime as our >> goal is bandwidth efficiency between the watcher and the network? >> I think that filter criteria will be modified by watchers a lot >> less regularly than the period of refresh subscriptions and so it >> is better to have some very small extra overhead when creating, >> modifying or deleting the filter than having to include the >> filter criteria in every refresh. I think some similar >> functionality to the partial drafts may be the way forward here. > > > As I commented earlier, I share your concern and will look into it > before the next version of the I-D is released. I have an idea here. THe idea is that, instead of sending the filter, the SUBSCRIBE refresh includes a hash of the filter as the body of the request (with a content-type along the lines of filter-hash or something). The server checks the hash to see if it maps against any existing filter that has been used in this dialog (and indeed, part of different dialogs too - would allow for sharing of filters). If so, the server acts as if that filter was in the body of the SUBSCRIBE. If not, it rejects teh request and the client can re-try with the full filter. Basically, this is caching of filter documents, using a hash of the document as a reference to a cache entry. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Thu May 29 13:12:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10671 for ; Thu, 29 May 2003 13:12:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4THCW106078 for simple-archive@odin.ietf.org; Thu, 29 May 2003 13:12:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4THCWB06075 for ; Thu, 29 May 2003 13:12:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10648; Thu, 29 May 2003 13:12:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQvS-0000nt-00; Thu, 29 May 2003 13:10:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LQvR-0000nq-00; Thu, 29 May 2003 13:10:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TH9BB05910; Thu, 29 May 2003 13:09:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TH8QB05890 for ; Thu, 29 May 2003 13:08:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10526 for ; Thu, 29 May 2003 13:08:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LQrU-0000mA-00 for simple@ietf.org; Thu, 29 May 2003 13:06:44 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LQrT-0000lw-00 for simple@ietf.org; Thu, 29 May 2003 13:06:43 -0400 Received: from dynamicsoft.com ([63.113.46.54]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4TH7jZE003484; Thu, 29 May 2003 13:07:45 -0400 (EDT) Message-ID: <3ED63E5C.9050403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org Subject: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <2038BCC78B1AD641891A0D1AE133DBB7FE7665@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7665@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, 29 May 2003 13:07:40 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >> As I stated in my earlier email regarding the requirement draft I >> have a concern with the replace semantics of the filter criteria >> in the Subscribe. I am concerned that the filter criteria could >> become quite large especially if the watcher has different filter >> criteria for different presentities within presence lists. Do we >> need to have every refresh subscriptions include all the filter >> criteria for every presentity being watching everytime as our >> goal is bandwidth efficiency between the watcher and the network? >> I think that filter criteria will be modified by watchers a lot >> less regularly than the period of refresh subscriptions and so it >> is better to have some very small extra overhead when creating, >> modifying or deleting the filter than having to include the >> filter criteria in every refresh. I think some similar >> functionality to the partial drafts may be the way forward here. > > > As I commented earlier, I share your concern and will look into it > before the next version of the I-D is released. I have an idea here. THe idea is that, instead of sending the filter, the SUBSCRIBE refresh includes a hash of the filter as the body of the request (with a content-type along the lines of filter-hash or something). The server checks the hash to see if it maps against any existing filter that has been used in this dialog (and indeed, part of different dialogs too - would allow for sharing of filters). If so, the server acts as if that filter was in the body of the SUBSCRIBE. If not, it rejects teh request and the client can re-try with the full filter. Basically, this is caching of filter documents, using a hash of the document as a reference to a cache entry. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 May 29 14:44: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 OAA13692; Thu, 29 May 2003 14:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSMx-0001Tv-00; Thu, 29 May 2003 14:43:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSMw-0001Ts-00; Thu, 29 May 2003 14:43:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TIf9B12105; Thu, 29 May 2003 14:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TIdtB12013 for ; Thu, 29 May 2003 14:39:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521 for ; Thu, 29 May 2003 14:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSI0-0001R5-00 for simple@ietf.org; Thu, 29 May 2003 14:38:12 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LSHy-0001Qk-00 for simple@ietf.org; Thu, 29 May 2003 14:38:10 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TIdF629008 for ; Thu, 29 May 2003 13:39:15 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054233546.936.212.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for BINPIDF/Filtering Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 14:39:06 -0400 Content-Transfer-Encoding: 7bit Slides for the BINPIDF and Filtering discussions are at http://www.nostrum.com/~rjsparks/BINPIDF_-_SIMPLE_Interim_-_May_2003.ppt http://www.nostrum.com/~rjsparks/Event_Notification_Filtering_-_SIMPLE_Interim_-_May_2003.ppt RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 14:45:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13728 for ; Thu, 29 May 2003 14:45:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TIj3J12244 for simple-archive@odin.ietf.org; Thu, 29 May 2003 14:45:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TIj3B12241 for ; Thu, 29 May 2003 14:45:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13692; Thu, 29 May 2003 14:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSMx-0001Tv-00; Thu, 29 May 2003 14:43:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSMw-0001Ts-00; Thu, 29 May 2003 14:43:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TIf9B12105; Thu, 29 May 2003 14:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TIdtB12013 for ; Thu, 29 May 2003 14:39:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13521 for ; Thu, 29 May 2003 14:39:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSI0-0001R5-00 for simple@ietf.org; Thu, 29 May 2003 14:38:12 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LSHy-0001Qk-00 for simple@ietf.org; Thu, 29 May 2003 14:38:10 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TIdF629008 for ; Thu, 29 May 2003 13:39:15 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054233546.936.212.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for BINPIDF/Filtering Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 14:39:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Slides for the BINPIDF and Filtering discussions are at http://www.nostrum.com/~rjsparks/BINPIDF_-_SIMPLE_Interim_-_May_2003.ppt http://www.nostrum.com/~rjsparks/Event_Notification_Filtering_-_SIMPLE_Interim_-_May_2003.ppt RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 15:04: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 PAA14650; Thu, 29 May 2003 15:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSgK-0001dL-00; Thu, 29 May 2003 15:03:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSgJ-0001dG-00; Thu, 29 May 2003 15:03:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJ1bB12883; Thu, 29 May 2003 15:01:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJ0LB12817 for ; Thu, 29 May 2003 15:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14313 for ; Thu, 29 May 2003 15:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSbm-0001aw-00 for simple@ietf.org; Thu, 29 May 2003 14:58:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LSbk-0001ap-00 for simple@ietf.org; Thu, 29 May 2003 14:58:36 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TIxf629185 for ; Thu, 29 May 2003 13:59:41 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054234772.1440.237.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Partial Notification discussion slides Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 14:59:32 -0400 Content-Transfer-Encoding: 7bit The slides for the next part of the agenda are now at http://www.nostrum.com/~rjsparks/Partial_Notifications.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 15:05:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14779 for ; Thu, 29 May 2003 15:05:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TJ55x13025 for simple-archive@odin.ietf.org; Thu, 29 May 2003 15:05:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJ55B13022 for ; Thu, 29 May 2003 15:05:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14650; Thu, 29 May 2003 15:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSgK-0001dL-00; Thu, 29 May 2003 15:03:20 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSgJ-0001dG-00; Thu, 29 May 2003 15:03:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJ1bB12883; Thu, 29 May 2003 15:01:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJ0LB12817 for ; Thu, 29 May 2003 15:00:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14313 for ; Thu, 29 May 2003 15:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSbm-0001aw-00 for simple@ietf.org; Thu, 29 May 2003 14:58:38 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LSbk-0001ap-00 for simple@ietf.org; Thu, 29 May 2003 14:58:36 -0400 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id h4TIxf629185 for ; Thu, 29 May 2003 13:59:41 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054234772.1440.237.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Partial Notification discussion slides Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 14:59:32 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The slides for the next part of the agenda are now at http://www.nostrum.com/~rjsparks/Partial_Notifications.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu May 29 15:15:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15900; Thu, 29 May 2003 15:15:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSqS-0001iT-00; Thu, 29 May 2003 15:13:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSqR-0001iQ-00; Thu, 29 May 2003 15:13:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJC1B14176; Thu, 29 May 2003 15:12:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJBvB14153 for ; Thu, 29 May 2003 15:11:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15493 for ; Thu, 29 May 2003 15:11:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSmy-0001h2-00 for simple@ietf.org; Thu, 29 May 2003 15:10:12 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LSmy-0001gn-00 for simple@ietf.org; Thu, 29 May 2003 15:10:12 -0400 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 h4TJBK629296 for ; Thu, 29 May 2003 14:11:20 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054235465.923.261.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Update: Agenda: SIMPLE Interim meeting 5/29-30]] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 15:11:06 -0400 Content-Transfer-Encoding: 7bit We've adjusted our remaining agenda time based on this afternoon's input as follows: Thursday May 29, 2003 current-1600 BINPIDF/Filtering/Partial Notification 1600-1800 remaining Message Sessions issues Friday May 30, 2003 0900-1030 What is a Tuple 1030-1200 RPIDs 1200-1300 Lunch 1300-1400 Publish 1400-1600 Data Manipulation RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Thu May 29 15:15:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15985 for ; Thu, 29 May 2003 15:15:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4TJFSO14324 for simple-archive@odin.ietf.org; Thu, 29 May 2003 15:15:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJFSB14321 for ; Thu, 29 May 2003 15:15:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15900; Thu, 29 May 2003 15:15:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSqS-0001iT-00; Thu, 29 May 2003 15:13:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LSqR-0001iQ-00; Thu, 29 May 2003 15:13:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJC1B14176; Thu, 29 May 2003 15:12:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4TJBvB14153 for ; Thu, 29 May 2003 15:11:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15493 for ; Thu, 29 May 2003 15:11:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LSmy-0001h2-00 for simple@ietf.org; Thu, 29 May 2003 15:10:12 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LSmy-0001gn-00 for simple@ietf.org; Thu, 29 May 2003 15:10:12 -0400 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 h4TJBK629296 for ; Thu, 29 May 2003 14:11:20 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054235465.923.261.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Update: Agenda: SIMPLE Interim meeting 5/29-30]] Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 29 May 2003 15:11:06 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We've adjusted our remaining agenda time based on this afternoon's input as follows: Thursday May 29, 2003 current-1600 BINPIDF/Filtering/Partial Notification 1600-1800 remaining Message Sessions issues Friday May 30, 2003 0900-1030 What is a Tuple 1030-1200 RPIDs 1200-1300 Lunch 1300-1400 Publish 1400-1600 Data Manipulation RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 09:08:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04944; Fri, 30 May 2003 09:08:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ljb7-0003xU-00; Fri, 30 May 2003 09:07:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ljb7-0003xR-00; Fri, 30 May 2003 09:07:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UD3dB32128; Fri, 30 May 2003 09:03:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UD1GB32057 for ; Fri, 30 May 2003 09:01:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04641 for ; Fri, 30 May 2003 09:01:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LjTp-0003s2-00 for simple@ietf.org; Fri, 30 May 2003 08:59:33 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LjTo-0003ry-00 for simple@ietf.org; Fri, 30 May 2003 08:59:32 -0400 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 h4UD0f606091 for ; Fri, 30 May 2003 08:00:41 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054299635.922.1.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for today's RPIDS/tuple discussion Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 May 2003 09:00:36 -0400 Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/IRT/papers/2003/RPIDS-Interim.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 09:09:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04964 for ; Fri, 30 May 2003 09:09:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UD8n600829 for simple-archive@odin.ietf.org; Fri, 30 May 2003 09:08:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UD8nB00826 for ; Fri, 30 May 2003 09:08:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04944; Fri, 30 May 2003 09:08:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ljb7-0003xU-00; Fri, 30 May 2003 09:07:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ljb7-0003xR-00; Fri, 30 May 2003 09:07:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UD3dB32128; Fri, 30 May 2003 09:03:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UD1GB32057 for ; Fri, 30 May 2003 09:01:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04641 for ; Fri, 30 May 2003 09:01:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LjTp-0003s2-00 for simple@ietf.org; Fri, 30 May 2003 08:59:33 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LjTo-0003ry-00 for simple@ietf.org; Fri, 30 May 2003 08:59:32 -0400 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 h4UD0f606091 for ; Fri, 30 May 2003 08:00:41 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054299635.922.1.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for today's RPIDS/tuple discussion Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 May 2003 09:00:36 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/IRT/papers/2003/RPIDS-Interim.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 09:51:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07243; Fri, 30 May 2003 09:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkG9-0004dm-00; Fri, 30 May 2003 09:49:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LkG8-0004dj-00; Fri, 30 May 2003 09:49:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDk9B03645; Fri, 30 May 2003 09:46:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDjWB03610 for ; Fri, 30 May 2003 09:45:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07048 for ; Fri, 30 May 2003 09:45:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkAe-0004az-00 for simple@ietf.org; Fri, 30 May 2003 09:43:48 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LkAd-0004aX-00 for simple@ietf.org; Fri, 30 May 2003 09:43:47 -0400 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 h4UDiu606527 for ; Fri, 30 May 2003 08:44:56 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054302295.935.55.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for this afternoon's discussions on publish and xcap Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 May 2003 09:44:56 -0400 Content-Transfer-Encoding: 7bit http://www.nostrum.com/~rjsparks/simple-interim-may03-publish.ppt http://www.nostrum.com/~rjsparks/simple-interim-may03-xcap.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 09:51:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07291 for ; Fri, 30 May 2003 09:51:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UDpET03921 for simple-archive@odin.ietf.org; Fri, 30 May 2003 09:51:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDpDB03918 for ; Fri, 30 May 2003 09:51:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07243; Fri, 30 May 2003 09:51:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkG9-0004dm-00; Fri, 30 May 2003 09:49:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LkG8-0004dj-00; Fri, 30 May 2003 09:49:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDk9B03645; Fri, 30 May 2003 09:46:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UDjWB03610 for ; Fri, 30 May 2003 09:45:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07048 for ; Fri, 30 May 2003 09:45:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LkAe-0004az-00 for simple@ietf.org; Fri, 30 May 2003 09:43:48 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LkAd-0004aX-00 for simple@ietf.org; Fri, 30 May 2003 09:43:47 -0400 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 h4UDiu606527 for ; Fri, 30 May 2003 08:44:56 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054302295.935.55.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Slides for this afternoon's discussions on publish and xcap Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 May 2003 09:44:56 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit http://www.nostrum.com/~rjsparks/simple-interim-may03-publish.ppt http://www.nostrum.com/~rjsparks/simple-interim-may03-xcap.ppt _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 10:38:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10739; Fri, 30 May 2003 10:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkzk-0005EN-00; Fri, 30 May 2003 10:36:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lkzj-0005EK-00; Fri, 30 May 2003 10:36:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEXCB07511; Fri, 30 May 2003 10:33:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEWUB07467 for ; Fri, 30 May 2003 10:32:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10468 for ; Fri, 30 May 2003 10:32:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lku5-00059W-00 for simple@ietf.org; Fri, 30 May 2003 10:30:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lku3-00058P-00 for simple@ietf.org; Fri, 30 May 2003 10:30:44 -0400 Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4UEVkZE003876; Fri, 30 May 2003 10:31:46 -0400 (EDT) Message-ID: <3ED76B4D.10504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Avshalom Houri , Paul Kyzivat , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052938287.2539.27.camel@verite.localdomain> In-Reply-To: <1052938287.2539.27.camel@verite.localdomain> 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, 30 May 2003 10:31:41 -0400 Content-Transfer-Encoding: 7bit The interim has motivated me to respond to this somewhat old thread. I think there is a distinction, and it lies with the model of how presence works. In my mind, there is an existing universe of data about users. This data is embedded in many, many places - in HLRs, in VLRs, in registrars, in corporate databases, in cell phones, in PBXs, etc. This data has meaning within the systems in which it resides, and there are protocols within those systems for manipulation of it. Protocols like LDAP, SIP REGISTER, SS7, etc. Separate from that is a presence system. The presence system provides a "front end" for this data below, allowing interested parties to subscribe to it, and based on authorization policies, receive notifications to it. PUBLISH is an interface between these existing systems and the presence system, providing a standardized way to move information between them. However, PUBLISH in no way replaces any of the above protocols. So, in the specific case of SIP, the existing system is the registrar. It has state, manipulated by REGISTER, and consumed by proxies for call routing. Separately, ontop of this system, lies a presence server. The registrar would push registration state into the presence server using PUBLISH. So, I would argue that a PUBLISH has no impact on registration state, unless there is some very odd, domain-specific policy that decides to make it that way. This isn't a PUBLISH specific issue. One can imagine that an enterprise has a web system where users login to the corporate website when they come to work. This login could trigger a sip registration to be created. We dont disallow this kind of thing, but there is no expectation that it exists as a general rule. -Jonathan R. Ben Campbell wrote: > On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: > >>If we were creating the SIP protocol today I am not sure that both >>REGISTER and PUBLISH would have been >>created. We would have created only one of them. Now we have both several >>questions may arise: > > > I agree we may not have gone the same route if we were inventing from > scratch. That is, of course, true of many things. However, REGISTER and > PUBLISH have different purposes. REGISTER puts rendezvous info into the > SIP network infrastructure--sort of a higer-layer route generation. > PUBLISH carries presence info to be distributed to watchers. Now, that > presence info _might_ be a superset of the rendezvous info, but it > doesn't have to be. > > >>* Is it "legal" for a system to add the contacts it got through PUBLISH to >>the registrar? > > > Assuming you mean in the broader sense of a location service, sure. It's > legal to put contacts into a location service from _any_ source. It is > up to the implementer to decide what sources make sense for his > implementation. (This particular case might not be a good idea, but the > protocol does not categorically rule out bad policy decisions.) > > >> Someone would like to reveal some contacts only to the users that can >>see her/his presence. > > > Sure. But as above, don't equate policy with protocol rules. There are > many policies a network could follow that would allow this bit of > choice. > > >>* Probably the same question from a different angle: What should be the >>awareness of the user >> to the system behavior. The user may think that if the PUBLISH have >>expired he/she is no longer >> available online while the system may use REGISTER in order to consider >>the user as online. > > > I don't think we have fully defined what it means for a publication to > expire. I would suggest it meanst that the watcher should consider the > presence state to be indeterminant. Indeterminant is not the same thing > as off-line. > > I don't see why presence expiration should necessarily imply anything > about registration state. Certainly, there is no protocol rule that > prevents an AoR from working, even if presence state indicates the user > is offline. If a user wants to make sure this does not happen, he could > simply set the same expiration for registered contacts as he does for > published presence state. > > Personally, I don't think we can pre-define any relationship between > REGISTER and PUBLISH. Such things are a matter of local policy. The > architecture draft may suggest some possible useful policies, but should > not preclude creativity in creating totally different policies. > > > >>Avshalom >> >> >> >> >> >>Paul Kyzivat >>07/05/2003 21:28 >> >>To >>Ben Campbell >>cc >>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG >>Subject >>Re: [Simple] PUBLISH and REGISTER relationship >> >> >> >> >> >> >>I'm assuming you are questioning the relationship between requests that >>start out somethin like: >> >> REGISTER sip:example.com >> To: sip:foo@example.com >> ... >> >>and >> >> PUBLISH sip:foo@example.com >> To: sip:foo@example.com >> ... >> >>If so, I think there is some probable precedence of the REGISTER over >>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for >>address sip:foo@example.com. It is not routed according to the prior set >>of registered contacts for that address. >> >>OTOH, the PUBLISH, at least in principle, is just an ordinary message, >>and is routed based on the registered contacts, plus local policy of the >>proxy/registrar. >> >>So, the REGISTER *could* have been installing a contact for the presence >>server itself. In that case, prior to the register the PUBLISH might >>have failed, whereas after it might succeed. I don't think the converse >>is a likely scenario. (That before the publish the register would fail, >>but after the register would succeed.) >> >>I do agree that there are similarities between REGISTER and PUBLISH. I >>can imagine a system that supports PUBLISH and not REGISTER, and does >>all routing based on presence, using the contact addresses in presence >>tuples. That would be an unusual sip system today, though it may be less >>so in the future. >> >>I also agree with Ben that there is plenty of opportunity for local >>policy to determine what happens here. I expect there will be plenty of >>systems where the registrar, presence server, and proxy are all bundled >>together and cooperate via local configuration. >> >> Paul >> >>Ben Campbell wrote: >> >>>I think that is entirely a question of local policy. There is no >>>protocol requirement for the two operations to be linked in any way, but >>>a given service provider might choose to do so. >>> >>>If you _do_ link them, you are making assumptions about a relationship >>>between the device doing the publishing and the device doing the >>>registering that may or may not exist. >>> >>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: >>> >>> >>>>In a system that has both a registrar and a presence server what should >> >>be >> >>>>the relationships between >>>>REGISTER and PUBLISH? >>>> >>>>* Should a REGISTER make the user on-line even though PUBLISH was not >> >>sent >> >>>>yet? >>>>* Should PUBLISH be considered as a login to the system as REGISTER? >>>> >>>>To some extent it seems that PUBLISH and REGISTER have a similar >>>>functionality but one is for the registrar >>>>while the other is for the presence server. >>>> >>>>Avshalom >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Fri May 30 10:38:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10765 for ; Fri, 30 May 2003 10:38:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEcMr08714 for simple-archive@odin.ietf.org; Fri, 30 May 2003 10:38:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEcLB08711 for ; Fri, 30 May 2003 10:38:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10739; Fri, 30 May 2003 10:38:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkzk-0005EN-00; Fri, 30 May 2003 10:36:36 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Lkzj-0005EK-00; Fri, 30 May 2003 10:36:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEXCB07511; Fri, 30 May 2003 10:33:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEWUB07467 for ; Fri, 30 May 2003 10:32:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10468 for ; Fri, 30 May 2003 10:32:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lku5-00059W-00 for simple@ietf.org; Fri, 30 May 2003 10:30:45 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lku3-00058P-00 for simple@ietf.org; Fri, 30 May 2003 10:30:44 -0400 Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4UEVkZE003876; Fri, 30 May 2003 10:31:46 -0400 (EDT) Message-ID: <3ED76B4D.10504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Avshalom Houri , Paul Kyzivat , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052938287.2539.27.camel@verite.localdomain> In-Reply-To: <1052938287.2539.27.camel@verite.localdomain> 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, 30 May 2003 10:31:41 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The interim has motivated me to respond to this somewhat old thread. I think there is a distinction, and it lies with the model of how presence works. In my mind, there is an existing universe of data about users. This data is embedded in many, many places - in HLRs, in VLRs, in registrars, in corporate databases, in cell phones, in PBXs, etc. This data has meaning within the systems in which it resides, and there are protocols within those systems for manipulation of it. Protocols like LDAP, SIP REGISTER, SS7, etc. Separate from that is a presence system. The presence system provides a "front end" for this data below, allowing interested parties to subscribe to it, and based on authorization policies, receive notifications to it. PUBLISH is an interface between these existing systems and the presence system, providing a standardized way to move information between them. However, PUBLISH in no way replaces any of the above protocols. So, in the specific case of SIP, the existing system is the registrar. It has state, manipulated by REGISTER, and consumed by proxies for call routing. Separately, ontop of this system, lies a presence server. The registrar would push registration state into the presence server using PUBLISH. So, I would argue that a PUBLISH has no impact on registration state, unless there is some very odd, domain-specific policy that decides to make it that way. This isn't a PUBLISH specific issue. One can imagine that an enterprise has a web system where users login to the corporate website when they come to work. This login could trigger a sip registration to be created. We dont disallow this kind of thing, but there is no expectation that it exists as a general rule. -Jonathan R. Ben Campbell wrote: > On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: > >>If we were creating the SIP protocol today I am not sure that both >>REGISTER and PUBLISH would have been >>created. We would have created only one of them. Now we have both several >>questions may arise: > > > I agree we may not have gone the same route if we were inventing from > scratch. That is, of course, true of many things. However, REGISTER and > PUBLISH have different purposes. REGISTER puts rendezvous info into the > SIP network infrastructure--sort of a higer-layer route generation. > PUBLISH carries presence info to be distributed to watchers. Now, that > presence info _might_ be a superset of the rendezvous info, but it > doesn't have to be. > > >>* Is it "legal" for a system to add the contacts it got through PUBLISH to >>the registrar? > > > Assuming you mean in the broader sense of a location service, sure. It's > legal to put contacts into a location service from _any_ source. It is > up to the implementer to decide what sources make sense for his > implementation. (This particular case might not be a good idea, but the > protocol does not categorically rule out bad policy decisions.) > > >> Someone would like to reveal some contacts only to the users that can >>see her/his presence. > > > Sure. But as above, don't equate policy with protocol rules. There are > many policies a network could follow that would allow this bit of > choice. > > >>* Probably the same question from a different angle: What should be the >>awareness of the user >> to the system behavior. The user may think that if the PUBLISH have >>expired he/she is no longer >> available online while the system may use REGISTER in order to consider >>the user as online. > > > I don't think we have fully defined what it means for a publication to > expire. I would suggest it meanst that the watcher should consider the > presence state to be indeterminant. Indeterminant is not the same thing > as off-line. > > I don't see why presence expiration should necessarily imply anything > about registration state. Certainly, there is no protocol rule that > prevents an AoR from working, even if presence state indicates the user > is offline. If a user wants to make sure this does not happen, he could > simply set the same expiration for registered contacts as he does for > published presence state. > > Personally, I don't think we can pre-define any relationship between > REGISTER and PUBLISH. Such things are a matter of local policy. The > architecture draft may suggest some possible useful policies, but should > not preclude creativity in creating totally different policies. > > > >>Avshalom >> >> >> >> >> >>Paul Kyzivat >>07/05/2003 21:28 >> >>To >>Ben Campbell >>cc >>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG >>Subject >>Re: [Simple] PUBLISH and REGISTER relationship >> >> >> >> >> >> >>I'm assuming you are questioning the relationship between requests that >>start out somethin like: >> >> REGISTER sip:example.com >> To: sip:foo@example.com >> ... >> >>and >> >> PUBLISH sip:foo@example.com >> To: sip:foo@example.com >> ... >> >>If so, I think there is some probable precedence of the REGISTER over >>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for >>address sip:foo@example.com. It is not routed according to the prior set >>of registered contacts for that address. >> >>OTOH, the PUBLISH, at least in principle, is just an ordinary message, >>and is routed based on the registered contacts, plus local policy of the >>proxy/registrar. >> >>So, the REGISTER *could* have been installing a contact for the presence >>server itself. In that case, prior to the register the PUBLISH might >>have failed, whereas after it might succeed. I don't think the converse >>is a likely scenario. (That before the publish the register would fail, >>but after the register would succeed.) >> >>I do agree that there are similarities between REGISTER and PUBLISH. I >>can imagine a system that supports PUBLISH and not REGISTER, and does >>all routing based on presence, using the contact addresses in presence >>tuples. That would be an unusual sip system today, though it may be less >>so in the future. >> >>I also agree with Ben that there is plenty of opportunity for local >>policy to determine what happens here. I expect there will be plenty of >>systems where the registrar, presence server, and proxy are all bundled >>together and cooperate via local configuration. >> >> Paul >> >>Ben Campbell wrote: >> >>>I think that is entirely a question of local policy. There is no >>>protocol requirement for the two operations to be linked in any way, but >>>a given service provider might choose to do so. >>> >>>If you _do_ link them, you are making assumptions about a relationship >>>between the device doing the publishing and the device doing the >>>registering that may or may not exist. >>> >>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: >>> >>> >>>>In a system that has both a registrar and a presence server what should >> >>be >> >>>>the relationships between >>>>REGISTER and PUBLISH? >>>> >>>>* Should a REGISTER make the user on-line even though PUBLISH was not >> >>sent >> >>>>yet? >>>>* Should PUBLISH be considered as a login to the system as REGISTER? >>>> >>>>To some extent it seems that PUBLISH and REGISTER have a similar >>>>functionality but one is for the registrar >>>>while the other is for the presence server. >>>> >>>>Avshalom >>>> >>>> >>>>_______________________________________________ >>>>Simple mailing list >>>>Simple@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 May 30 10:41:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10845; Fri, 30 May 2003 10:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll2X-0005Fh-00; Fri, 30 May 2003 10:39:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ll2W-0005Fa-00; Fri, 30 May 2003 10:39:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEa5B07739; Fri, 30 May 2003 10:36:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEYQB07559 for ; Fri, 30 May 2003 10:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10608 for ; Fri, 30 May 2003 10:34:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkvx-0005CN-00 for simple@ietf.org; Fri, 30 May 2003 10:32:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Lkvw-0005CG-00 for simple@ietf.org; Fri, 30 May 2003 10:32:40 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEYJD15185 for ; Fri, 30 May 2003 17:34:19 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:34:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:34:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Scope of filter addressing (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7672@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMl93Isnq2WctX1Sz+KgyocdQD9awAwC7/g To: , X-OriginalArrivalTime: 30 May 2003 14:34:19.0681 (UTC) FILETIME=[8E201110:01C326B8] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4UEYQB07560 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:34:19 +0300 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UEa5B07739 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA10845 > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > [AA] The text at issue here is in clause 4.1 “If the URI > indicated by the filter criteria is for one resource who's > URI is NOT one of the URIs that result from a lookup, by the > RLS, on the Request-URI, the filter criteria are propagated > to all the fanned out subscriptions. This is to accommodate > the scenario where the > subscriber knows that there are sub-lists in the list that > the original subscription was sent to, and the subscriber > wishes to set a filter criteria for a resource in that sub-list.” > > [AA] The issue that I am identifying is when the filter > criteria corresponds to a resource that is a child of a sub > list of the list. For instance 3 lists A, B, and C, each in > different domains where A is a child of B and B is a child of > C: CàBàA > > [AA] Now in the subscription to C I want to be able to > include filter criteria that is targeted at a particular > member of list A (Amember1). In order to target the URI > member of A in the subscription to list C we need to specify > the path of the URI: C->B->A->Amember1. Maybe Xpath can also > be used for this purpose? For the reasons stated I think > simply propagating the filter criteria corresponding to a > resource unknown to the RLS to every descendent, (as I > understand from this text is proposed), is a bad idea. > Instead the filter criteria should only be propagated down > the specific branch that contains the target. In addition to > the issues raised earlier, I think also there may be privacy > concerns with broadcasting the filter criteria to other > branches of the tree that are possibly in different domains > from the target (i.e Do you want your company to know who all > your personal contacts are?) As was discussed in the interim meeting, this URI approach might not be good enough to describe wild cards (this filter applies to all people in nokia.com, people is a georgraphic location (this filter applies to people in helsinki), etc. This is certainly expanding the scope of this work and the question is do we need such scope. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 10:41:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10901 for ; Fri, 30 May 2003 10:41:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEfFh08902 for simple-archive@odin.ietf.org; Fri, 30 May 2003 10:41:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEfFB08899 for ; Fri, 30 May 2003 10:41:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10845; Fri, 30 May 2003 10:41:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll2X-0005Fh-00; Fri, 30 May 2003 10:39:29 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ll2W-0005Fa-00; Fri, 30 May 2003 10:39:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEa5B07739; Fri, 30 May 2003 10:36:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEYQB07559 for ; Fri, 30 May 2003 10:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10608 for ; Fri, 30 May 2003 10:34:20 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lkvx-0005CN-00 for simple@ietf.org; Fri, 30 May 2003 10:32:41 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19Lkvw-0005CG-00 for simple@ietf.org; Fri, 30 May 2003 10:32:40 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEYJD15185 for ; Fri, 30 May 2003 17:34:19 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:34:19 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:34:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Scope of filter addressing (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7672@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMl93Isnq2WctX1Sz+KgyocdQD9awAwC7/g To: , X-OriginalArrivalTime: 30 May 2003 14:34:19.0681 (UTC) FILETIME=[8E201110:01C326B8] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4UEYQB07560 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:34:19 +0300 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UEa5B07739 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UEfFB08899 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > [AA] The text at issue here is in clause 4.1 “If the URI > indicated by the filter criteria is for one resource who's > URI is NOT one of the URIs that result from a lookup, by the > RLS, on the Request-URI, the filter criteria are propagated > to all the fanned out subscriptions. This is to accommodate > the scenario where the > subscriber knows that there are sub-lists in the list that > the original subscription was sent to, and the subscriber > wishes to set a filter criteria for a resource in that sub-list.” > > [AA] The issue that I am identifying is when the filter > criteria corresponds to a resource that is a child of a sub > list of the list. For instance 3 lists A, B, and C, each in > different domains where A is a child of B and B is a child of > C: CàBàA > > [AA] Now in the subscription to C I want to be able to > include filter criteria that is targeted at a particular > member of list A (Amember1). In order to target the URI > member of A in the subscription to list C we need to specify > the path of the URI: C->B->A->Amember1. Maybe Xpath can also > be used for this purpose? For the reasons stated I think > simply propagating the filter criteria corresponding to a > resource unknown to the RLS to every descendent, (as I > understand from this text is proposed), is a bad idea. > Instead the filter criteria should only be propagated down > the specific branch that contains the target. In addition to > the issues raised earlier, I think also there may be privacy > concerns with broadcasting the filter criteria to other > branches of the tree that are possibly in different domains > from the target (i.e Do you want your company to know who all > your personal contacts are?) As was discussed in the interim meeting, this URI approach might not be good enough to describe wild cards (this filter applies to all people in nokia.com, people is a georgraphic location (this filter applies to people in helsinki), etc. This is certainly expanding the scope of this work and the question is do we need such scope. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 10:55:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11377; Fri, 30 May 2003 10:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlGd-0005Lh-00; Fri, 30 May 2003 10:54:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlGc-0005Le-00; Fri, 30 May 2003 10:54:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEoSB09355; Fri, 30 May 2003 10:50:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEhPB09008 for ; Fri, 30 May 2003 10:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10997 for ; Fri, 30 May 2003 10:43:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll4d-0005Gv-00 for simple@ietf.org; Fri, 30 May 2003 10:41:39 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Ll4c-0005Gh-00 for simple@ietf.org; Fri, 30 May 2003 10:41:38 -0400 Received: from LOCALHOST (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h4UEgo8w055177; Fri, 30 May 2003 09:42:53 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] PUBLISH and REGISTER relationship From: Ben Campbell To: Jonathan Rosenberg Cc: Avshalom Houri , Paul Kyzivat , Simple WG In-Reply-To: <3ED76B4D.10504@dynamicsoft.com> References: <1052938287.2539.27.camel@verite.localdomain> <3ED76B4D.10504@dynamicsoft.com> Content-Type: text/plain Message-Id: <1054305744.1215.19.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 30 May 2003 09:42:25 -0500 Content-Transfer-Encoding: 7bit On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg wrote: > The interim has motivated me to respond to this somewhat old thread. > > I think there is a distinction, and it lies with the model of how > presence works. > > In my mind, there is an existing universe of data about users. This > data is embedded in many, many places - in HLRs, in VLRs, in > registrars, in corporate databases, in cell phones, in PBXs, etc. This > data has meaning within the systems in which it resides, and there are > protocols within those systems for manipulation of it. Protocols like > LDAP, SIP REGISTER, SS7, etc. > > Separate from that is a presence system. The presence system provides > a "front end" for this data below, allowing interested parties to > subscribe to it, and based on authorization policies, receive > notifications to it. PUBLISH is an interface between these existing > systems and the presence system, providing a standardized way to move > information between them. > > However, PUBLISH in no way replaces any of the above protocols. > > So, in the specific case of SIP, the existing system is the registrar. > It has state, manipulated by REGISTER, and consumed by proxies for > call routing. Separately, ontop of this system, lies a presence > server. The registrar would push registration state into the presence > server using PUBLISH. > > So, I would argue that a PUBLISH has no impact on registration state, > unless there is some very odd, domain-specific policy that decides to > make it that way. This isn't a PUBLISH specific issue. One can imagine > that an enterprise has a web system where users login to the corporate > website when they come to work. This login could trigger a sip > registration to be created. We dont disallow this kind of thing, but > there is no expectation that it exists as a general rule. > I will go further and say that there is no SIMPLE requirement that REGISTER and PUBLISH are related in any way. REGISTER _might_ affect presence state in the way you mention above, and probably will for most systems. But if someone builds a system in which it does not, that system is not in violation of any SIMPLE principle. Just because it is extremely useful does not make it required. > -Jonathan R. > > Ben Campbell wrote: > > On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: > > > >>If we were creating the SIP protocol today I am not sure that both > >>REGISTER and PUBLISH would have been > >>created. We would have created only one of them. Now we have both several > >>questions may arise: > > > > > > I agree we may not have gone the same route if we were inventing from > > scratch. That is, of course, true of many things. However, REGISTER and > > PUBLISH have different purposes. REGISTER puts rendezvous info into the > > SIP network infrastructure--sort of a higer-layer route generation. > > PUBLISH carries presence info to be distributed to watchers. Now, that > > presence info _might_ be a superset of the rendezvous info, but it > > doesn't have to be. > > > > > >>* Is it "legal" for a system to add the contacts it got through PUBLISH to > >>the registrar? > > > > > > Assuming you mean in the broader sense of a location service, sure. It's > > legal to put contacts into a location service from _any_ source. It is > > up to the implementer to decide what sources make sense for his > > implementation. (This particular case might not be a good idea, but the > > protocol does not categorically rule out bad policy decisions.) > > > > > >> Someone would like to reveal some contacts only to the users that can > >>see her/his presence. > > > > > > Sure. But as above, don't equate policy with protocol rules. There are > > many policies a network could follow that would allow this bit of > > choice. > > > > > >>* Probably the same question from a different angle: What should be the > >>awareness of the user > >> to the system behavior. The user may think that if the PUBLISH have > >>expired he/she is no longer > >> available online while the system may use REGISTER in order to consider > >>the user as online. > > > > > > I don't think we have fully defined what it means for a publication to > > expire. I would suggest it meanst that the watcher should consider the > > presence state to be indeterminant. Indeterminant is not the same thing > > as off-line. > > > > I don't see why presence expiration should necessarily imply anything > > about registration state. Certainly, there is no protocol rule that > > prevents an AoR from working, even if presence state indicates the user > > is offline. If a user wants to make sure this does not happen, he could > > simply set the same expiration for registered contacts as he does for > > published presence state. > > > > Personally, I don't think we can pre-define any relationship between > > REGISTER and PUBLISH. Such things are a matter of local policy. The > > architecture draft may suggest some possible useful policies, but should > > not preclude creativity in creating totally different policies. > > > > > > > >>Avshalom > >> > >> > >> > >> > >> > >>Paul Kyzivat > >>07/05/2003 21:28 > >> > >>To > >>Ben Campbell > >>cc > >>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG > >>Subject > >>Re: [Simple] PUBLISH and REGISTER relationship > >> > >> > >> > >> > >> > >> > >>I'm assuming you are questioning the relationship between requests that > >>start out somethin like: > >> > >> REGISTER sip:example.com > >> To: sip:foo@example.com > >> ... > >> > >>and > >> > >> PUBLISH sip:foo@example.com > >> To: sip:foo@example.com > >> ... > >> > >>If so, I think there is some probable precedence of the REGISTER over > >>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for > >>address sip:foo@example.com. It is not routed according to the prior set > >>of registered contacts for that address. > >> > >>OTOH, the PUBLISH, at least in principle, is just an ordinary message, > >>and is routed based on the registered contacts, plus local policy of the > >>proxy/registrar. > >> > >>So, the REGISTER *could* have been installing a contact for the presence > >>server itself. In that case, prior to the register the PUBLISH might > >>have failed, whereas after it might succeed. I don't think the converse > >>is a likely scenario. (That before the publish the register would fail, > >>but after the register would succeed.) > >> > >>I do agree that there are similarities between REGISTER and PUBLISH. I > >>can imagine a system that supports PUBLISH and not REGISTER, and does > >>all routing based on presence, using the contact addresses in presence > >>tuples. That would be an unusual sip system today, though it may be less > >>so in the future. > >> > >>I also agree with Ben that there is plenty of opportunity for local > >>policy to determine what happens here. I expect there will be plenty of > >>systems where the registrar, presence server, and proxy are all bundled > >>together and cooperate via local configuration. > >> > >> Paul > >> > >>Ben Campbell wrote: > >> > >>>I think that is entirely a question of local policy. There is no > >>>protocol requirement for the two operations to be linked in any way, but > >>>a given service provider might choose to do so. > >>> > >>>If you _do_ link them, you are making assumptions about a relationship > >>>between the device doing the publishing and the device doing the > >>>registering that may or may not exist. > >>> > >>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: > >>> > >>> > >>>>In a system that has both a registrar and a presence server what should > >> > >>be > >> > >>>>the relationships between > >>>>REGISTER and PUBLISH? > >>>> > >>>>* Should a REGISTER make the user on-line even though PUBLISH was not > >> > >>sent > >> > >>>>yet? > >>>>* Should PUBLISH be considered as a login to the system as REGISTER? > >>>> > >>>>To some extent it seems that PUBLISH and REGISTER have a similar > >>>>functionality but one is for the registrar > >>>>while the other is for the presence server. > >>>> > >>>>Avshalom > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 10:56:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11431 for ; Fri, 30 May 2003 10:56:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEtni09583 for simple-archive@odin.ietf.org; Fri, 30 May 2003 10:55:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEtnB09580 for ; Fri, 30 May 2003 10:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11377; Fri, 30 May 2003 10:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlGd-0005Lh-00; Fri, 30 May 2003 10:54:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlGc-0005Le-00; Fri, 30 May 2003 10:54:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEoSB09355; Fri, 30 May 2003 10:50:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEhPB09008 for ; Fri, 30 May 2003 10:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10997 for ; Fri, 30 May 2003 10:43:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll4d-0005Gv-00 for simple@ietf.org; Fri, 30 May 2003 10:41:39 -0400 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Ll4c-0005Gh-00 for simple@ietf.org; Fri, 30 May 2003 10:41:38 -0400 Received: from LOCALHOST (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id h4UEgo8w055177; Fri, 30 May 2003 09:42:53 -0500 (CDT) (envelope-from bcampbell@dynamicsoft.com) Subject: Re: [Simple] PUBLISH and REGISTER relationship From: Ben Campbell To: Jonathan Rosenberg Cc: Avshalom Houri , Paul Kyzivat , Simple WG In-Reply-To: <3ED76B4D.10504@dynamicsoft.com> References: <1052938287.2539.27.camel@verite.localdomain> <3ED76B4D.10504@dynamicsoft.com> Content-Type: text/plain Message-Id: <1054305744.1215.19.camel@verite.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.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: 30 May 2003 09:42:25 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg wrote: > The interim has motivated me to respond to this somewhat old thread. > > I think there is a distinction, and it lies with the model of how > presence works. > > In my mind, there is an existing universe of data about users. This > data is embedded in many, many places - in HLRs, in VLRs, in > registrars, in corporate databases, in cell phones, in PBXs, etc. This > data has meaning within the systems in which it resides, and there are > protocols within those systems for manipulation of it. Protocols like > LDAP, SIP REGISTER, SS7, etc. > > Separate from that is a presence system. The presence system provides > a "front end" for this data below, allowing interested parties to > subscribe to it, and based on authorization policies, receive > notifications to it. PUBLISH is an interface between these existing > systems and the presence system, providing a standardized way to move > information between them. > > However, PUBLISH in no way replaces any of the above protocols. > > So, in the specific case of SIP, the existing system is the registrar. > It has state, manipulated by REGISTER, and consumed by proxies for > call routing. Separately, ontop of this system, lies a presence > server. The registrar would push registration state into the presence > server using PUBLISH. > > So, I would argue that a PUBLISH has no impact on registration state, > unless there is some very odd, domain-specific policy that decides to > make it that way. This isn't a PUBLISH specific issue. One can imagine > that an enterprise has a web system where users login to the corporate > website when they come to work. This login could trigger a sip > registration to be created. We dont disallow this kind of thing, but > there is no expectation that it exists as a general rule. > I will go further and say that there is no SIMPLE requirement that REGISTER and PUBLISH are related in any way. REGISTER _might_ affect presence state in the way you mention above, and probably will for most systems. But if someone builds a system in which it does not, that system is not in violation of any SIMPLE principle. Just because it is extremely useful does not make it required. > -Jonathan R. > > Ben Campbell wrote: > > On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: > > > >>If we were creating the SIP protocol today I am not sure that both > >>REGISTER and PUBLISH would have been > >>created. We would have created only one of them. Now we have both several > >>questions may arise: > > > > > > I agree we may not have gone the same route if we were inventing from > > scratch. That is, of course, true of many things. However, REGISTER and > > PUBLISH have different purposes. REGISTER puts rendezvous info into the > > SIP network infrastructure--sort of a higer-layer route generation. > > PUBLISH carries presence info to be distributed to watchers. Now, that > > presence info _might_ be a superset of the rendezvous info, but it > > doesn't have to be. > > > > > >>* Is it "legal" for a system to add the contacts it got through PUBLISH to > >>the registrar? > > > > > > Assuming you mean in the broader sense of a location service, sure. It's > > legal to put contacts into a location service from _any_ source. It is > > up to the implementer to decide what sources make sense for his > > implementation. (This particular case might not be a good idea, but the > > protocol does not categorically rule out bad policy decisions.) > > > > > >> Someone would like to reveal some contacts only to the users that can > >>see her/his presence. > > > > > > Sure. But as above, don't equate policy with protocol rules. There are > > many policies a network could follow that would allow this bit of > > choice. > > > > > >>* Probably the same question from a different angle: What should be the > >>awareness of the user > >> to the system behavior. The user may think that if the PUBLISH have > >>expired he/she is no longer > >> available online while the system may use REGISTER in order to consider > >>the user as online. > > > > > > I don't think we have fully defined what it means for a publication to > > expire. I would suggest it meanst that the watcher should consider the > > presence state to be indeterminant. Indeterminant is not the same thing > > as off-line. > > > > I don't see why presence expiration should necessarily imply anything > > about registration state. Certainly, there is no protocol rule that > > prevents an AoR from working, even if presence state indicates the user > > is offline. If a user wants to make sure this does not happen, he could > > simply set the same expiration for registered contacts as he does for > > published presence state. > > > > Personally, I don't think we can pre-define any relationship between > > REGISTER and PUBLISH. Such things are a matter of local policy. The > > architecture draft may suggest some possible useful policies, but should > > not preclude creativity in creating totally different policies. > > > > > > > >>Avshalom > >> > >> > >> > >> > >> > >>Paul Kyzivat > >>07/05/2003 21:28 > >> > >>To > >>Ben Campbell > >>cc > >>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG > >>Subject > >>Re: [Simple] PUBLISH and REGISTER relationship > >> > >> > >> > >> > >> > >> > >>I'm assuming you are questioning the relationship between requests that > >>start out somethin like: > >> > >> REGISTER sip:example.com > >> To: sip:foo@example.com > >> ... > >> > >>and > >> > >> PUBLISH sip:foo@example.com > >> To: sip:foo@example.com > >> ... > >> > >>If so, I think there is some probable precedence of the REGISTER over > >>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for > >>address sip:foo@example.com. It is not routed according to the prior set > >>of registered contacts for that address. > >> > >>OTOH, the PUBLISH, at least in principle, is just an ordinary message, > >>and is routed based on the registered contacts, plus local policy of the > >>proxy/registrar. > >> > >>So, the REGISTER *could* have been installing a contact for the presence > >>server itself. In that case, prior to the register the PUBLISH might > >>have failed, whereas after it might succeed. I don't think the converse > >>is a likely scenario. (That before the publish the register would fail, > >>but after the register would succeed.) > >> > >>I do agree that there are similarities between REGISTER and PUBLISH. I > >>can imagine a system that supports PUBLISH and not REGISTER, and does > >>all routing based on presence, using the contact addresses in presence > >>tuples. That would be an unusual sip system today, though it may be less > >>so in the future. > >> > >>I also agree with Ben that there is plenty of opportunity for local > >>policy to determine what happens here. I expect there will be plenty of > >>systems where the registrar, presence server, and proxy are all bundled > >>together and cooperate via local configuration. > >> > >> Paul > >> > >>Ben Campbell wrote: > >> > >>>I think that is entirely a question of local policy. There is no > >>>protocol requirement for the two operations to be linked in any way, but > >>>a given service provider might choose to do so. > >>> > >>>If you _do_ link them, you are making assumptions about a relationship > >>>between the device doing the publishing and the device doing the > >>>registering that may or may not exist. > >>> > >>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: > >>> > >>> > >>>>In a system that has both a registrar and a presence server what should > >> > >>be > >> > >>>>the relationships between > >>>>REGISTER and PUBLISH? > >>>> > >>>>* Should a REGISTER make the user on-line even though PUBLISH was not > >> > >>sent > >> > >>>>yet? > >>>>* Should PUBLISH be considered as a login to the system as REGISTER? > >>>> > >>>>To some extent it seems that PUBLISH and REGISTER have a similar > >>>>functionality but one is for the registrar > >>>>while the other is for the presence server. > >>>> > >>>>Avshalom > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 10:57:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11520; Fri, 30 May 2003 10:57:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlIZ-0005NR-00; Fri, 30 May 2003 10:56:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlIZ-0005NO-00; Fri, 30 May 2003 10:56:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEqUB09420; Fri, 30 May 2003 10:52:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEiAB09051 for ; Fri, 30 May 2003 10:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11022 for ; Fri, 30 May 2003 10:44:04 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll5N-0005HO-00 for simple@ietf.org; Fri, 30 May 2003 10:42:25 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Ll5M-0005HI-00 for simple@ietf.org; Fri, 30 May 2003 10:42:24 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEi3W22568 for ; Fri, 30 May 2003 17:44:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:44:03 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:44:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Use of require header in SUBSCRIBE with a filter (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7673@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMl93Isnq2WctX1Sz+KgyocdQD9awAwSIxQ To: , X-OriginalArrivalTime: 30 May 2003 14:44:03.0695 (UTC) FILETIME=[EA3987F0:01C326B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4UEiAB09052 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:44:03 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > > > > > > I think we need a separate mechanism to indicate the > > difference between options 2 and 3. Also the UAC should be > > able to indicate whether option 2 is acceptable since option > > 2 could result in a large presence document being sent in a > > Notify, which may not be acceptable to the UAC. > > I will remove references to the word "ignore" in the next > version. If a server does not like a filter, it rejects it. > When it comes to authorisation, the server can examine the > filter after its has applied the authorisation policy. I'll > clarify that also. > > [AA] This is certainly one approach we could take however > this means that if I would like to use filtering but I am > willing to accept the subscription without filtering then I > may have to make two subscription attempts one with and one > without filtering. It seems to me that it would be more > efficient to use the SIP extension use negotiation > capabilities (Supported and Require) for a more efficient and > flexible mechanism. This is also along the lines of what is > currently proposed in draft-lonnfors-simple-partial-notify > where the option is there to indicate whether the use of the > extension is required or not. IMO it would make sense to be > consistent with subscription state handling for both partial > notifications and filtering. > Firstly, I was just agreed in the interim meeting that this require-header in partial notification is not necessary and will be removed. It is widely accepted that it is a server choice to honour filters. Do we need to change that? I need input from others on the list. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 10:58:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11587 for ; Fri, 30 May 2003 10:58:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UEvnv09828 for simple-archive@odin.ietf.org; Fri, 30 May 2003 10:57:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEvnB09825 for ; Fri, 30 May 2003 10:57:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11520; Fri, 30 May 2003 10:57:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlIZ-0005NR-00; Fri, 30 May 2003 10:56:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlIZ-0005NO-00; Fri, 30 May 2003 10:56:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEqUB09420; Fri, 30 May 2003 10:52:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEiAB09051 for ; Fri, 30 May 2003 10:44:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11022 for ; Fri, 30 May 2003 10:44:04 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll5N-0005HO-00 for simple@ietf.org; Fri, 30 May 2003 10:42:25 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Ll5M-0005HI-00 for simple@ietf.org; Fri, 30 May 2003 10:42:24 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEi3W22568 for ; Fri, 30 May 2003 17:44:04 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:44:03 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:44:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Use of require header in SUBSCRIBE with a filter (was: RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7673@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMl93Isnq2WctX1Sz+KgyocdQD9awAwSIxQ To: , X-OriginalArrivalTime: 30 May 2003 14:44:03.0695 (UTC) FILETIME=[EA3987F0:01C326B9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4UEiAB09052 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:44:03 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > > > > > > I think we need a separate mechanism to indicate the > > difference between options 2 and 3. Also the UAC should be > > able to indicate whether option 2 is acceptable since option > > 2 could result in a large presence document being sent in a > > Notify, which may not be acceptable to the UAC. > > I will remove references to the word "ignore" in the next > version. If a server does not like a filter, it rejects it. > When it comes to authorisation, the server can examine the > filter after its has applied the authorisation policy. I'll > clarify that also. > > [AA] This is certainly one approach we could take however > this means that if I would like to use filtering but I am > willing to accept the subscription without filtering then I > may have to make two subscription attempts one with and one > without filtering. It seems to me that it would be more > efficient to use the SIP extension use negotiation > capabilities (Supported and Require) for a more efficient and > flexible mechanism. This is also along the lines of what is > currently proposed in draft-lonnfors-simple-partial-notify > where the option is there to indicate whether the use of the > extension is required or not. IMO it would make sense to be > consistent with subscription state handling for both partial > notifications and filtering. > Firstly, I was just agreed in the interim meeting that this require-header in partial notification is not necessary and will be removed. It is widely accepted that it is a server choice to honour filters. Do we need to change that? I need input from others on the list. Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 11:00: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 LAA11701; Fri, 30 May 2003 11:00:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlLY-0005Pj-00; Fri, 30 May 2003 10:59:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlLY-0005Pg-00; Fri, 30 May 2003 10:59:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEtaB09575; Fri, 30 May 2003 10:55:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEkeB09168 for ; Fri, 30 May 2003 10:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11127 for ; Fri, 30 May 2003 10:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll7n-0005IY-00 for simple@ietf.org; Fri, 30 May 2003 10:44:55 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Ll7m-0005I9-00 for simple@ietf.org; Fri, 30 May 2003 10:44:54 -0400 Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4UEk0ZE003886; Fri, 30 May 2003 10:46:01 -0400 (EDT) Message-ID: <3ED76EA4.9080706@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Avshalom Houri , Paul Kyzivat , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052938287.2539.27.camel@verite.localdomain> <3ED76B4D.10504@dynamicsoft.com> <1054305744.1215.19.camel@verite.localdomain> In-Reply-To: <1054305744.1215.19.camel@verite.localdomain> 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, 30 May 2003 10:45:56 -0400 Content-Transfer-Encoding: 7bit Ben Campbell wrote: >>So, I would argue that a PUBLISH has no impact on registration state, >>unless there is some very odd, domain-specific policy that decides to >>make it that way. This isn't a PUBLISH specific issue. One can imagine >>that an enterprise has a web system where users login to the corporate >>website when they come to work. This login could trigger a sip >>registration to be created. We dont disallow this kind of thing, but >>there is no expectation that it exists as a general rule. >> > > > I will go further and say that there is no SIMPLE requirement that > REGISTER and PUBLISH are related in any way. REGISTER _might_ affect > presence state in the way you mention above, and probably will for most > systems. But if someone builds a system in which it does not, that > system is not in violation of any SIMPLE principle. Just because it is > extremely useful does not make it required. Agreed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Fri May 30 11:01:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11736 for ; Fri, 30 May 2003 11:01:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UF0ta10116 for simple-archive@odin.ietf.org; Fri, 30 May 2003 11:00:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF0sB10113 for ; Fri, 30 May 2003 11:00:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11701; Fri, 30 May 2003 11:00:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlLY-0005Pj-00; Fri, 30 May 2003 10:59:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlLY-0005Pg-00; Fri, 30 May 2003 10:59:08 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEtaB09575; Fri, 30 May 2003 10:55:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEkeB09168 for ; Fri, 30 May 2003 10:46:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11127 for ; Fri, 30 May 2003 10:46:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ll7n-0005IY-00 for simple@ietf.org; Fri, 30 May 2003 10:44:55 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Ll7m-0005I9-00 for simple@ietf.org; Fri, 30 May 2003 10:44:54 -0400 Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4UEk0ZE003886; Fri, 30 May 2003 10:46:01 -0400 (EDT) Message-ID: <3ED76EA4.9080706@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Avshalom Houri , Paul Kyzivat , Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship References: <1052938287.2539.27.camel@verite.localdomain> <3ED76B4D.10504@dynamicsoft.com> <1054305744.1215.19.camel@verite.localdomain> In-Reply-To: <1054305744.1215.19.camel@verite.localdomain> 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, 30 May 2003 10:45:56 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: >>So, I would argue that a PUBLISH has no impact on registration state, >>unless there is some very odd, domain-specific policy that decides to >>make it that way. This isn't a PUBLISH specific issue. One can imagine >>that an enterprise has a web system where users login to the corporate >>website when they come to work. This login could trigger a sip >>registration to be created. We dont disallow this kind of thing, but >>there is no expectation that it exists as a general rule. >> > > > I will go further and say that there is no SIMPLE requirement that > REGISTER and PUBLISH are related in any way. REGISTER _might_ affect > presence state in the way you mention above, and probably will for most > systems. But if someone builds a system in which it does not, that > system is not in violation of any SIMPLE principle. Just because it is > extremely useful does not make it required. Agreed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 May 30 11:02: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 LAA11765; Fri, 30 May 2003 11:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlNc-0005QU-00; Fri, 30 May 2003 11:01:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlNc-0005QR-00; Fri, 30 May 2003 11:01:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEvgB09807; Fri, 30 May 2003 10:57:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEo5B09319 for ; Fri, 30 May 2003 10:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11245 for ; Fri, 30 May 2003 10:49:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlB5-0005Jm-00 for simple@ietf.org; Fri, 30 May 2003 10:48:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19LlB4-0005Jj-00 for simple@ietf.org; Fri, 30 May 2003 10:48:18 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEnwD25295 for ; Fri, 30 May 2003 17:49:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:49:57 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:49:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Use of 202 response for subscription with filter (was :RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7674@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMl93Isnq2WctX1Sz+KgyocdQD9awAwnxwg To: , X-OriginalArrivalTime: 30 May 2003 14:49:57.0797 (UTC) FILETIME=[BD493550:01C326BA] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4UEo5B09320 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:49:57 +0300 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UEvgB09807 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11765 > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > > > > > Next comment relates to clause 3.3.4 Subscriber Interpreting > > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > > Requests, and clause 5.4 Handling Abnormal Cases: > > > > The meaning of 200 and 202 responses to Subscribe requests is > > already defined in RFC 3265 and they relate to the state of > > the subscription I don’t think we should further extend their > > meaning to also include a meaning to the state of the filter > > criteria. It seems the server has four basic options: > > > > 1) It can accept the subscription and also accept the filter > > criteria. – 200 OK > > 2) It can accept the subscription but ignore all the filter > > criteria - 200 OK > > 3) It can reject the subscription (which also rejects the > > filter criteria) - 4xxx > > 4) It can indicate that the subscription has been > > understood, and that authorization may or may not have been > > granted. - 202 > > I think the text as it is now is ok. Some implementations of > the server might want to examine the filter after responding > to the SUBSCRIBE. A 202 in this case is needed. > > [AA] My concern is with extending the meaning of 200 OK and > 202 from that stated in RFC 3265. The text of concern is in > clause 5.2 “A "200" response indicates that the subscription > has been accepted, the user is authorized and the filter is > accepted.” AND “A "202" response also indicates that the > filter criteria have not been accepted yet.” > > [AA] IMO even if we go with the approach of rejecting the > subscription if the filter criteria is rejected we do not > need this text since the RFC 3265 wording still applies – the > subscription is either rejected or authorised or pending. If > the implementation wants to examine the filter criteria > before authorising the subscription then a 202 is appropriate > and I think this is covered in 3265 as well. If we choose to > always reject the subscription if the filter criteria is not > acceptable then all we need to state in the draft is that > rejection of the filter criteria means that the subscription > must also be rejected as you propose below. > I still think we need to spell it out in the filtering draft. What do you think Adam? /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 11:03:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11808 for ; Fri, 30 May 2003 11:03:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UF32P10271 for simple-archive@odin.ietf.org; Fri, 30 May 2003 11:03:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF32B10268 for ; Fri, 30 May 2003 11:03:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11765; Fri, 30 May 2003 11:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlNc-0005QU-00; Fri, 30 May 2003 11:01:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlNc-0005QR-00; Fri, 30 May 2003 11:01:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEvgB09807; Fri, 30 May 2003 10:57:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEo5B09319 for ; Fri, 30 May 2003 10:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11245 for ; Fri, 30 May 2003 10:49:58 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlB5-0005Jm-00 for simple@ietf.org; Fri, 30 May 2003 10:48:19 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19LlB4-0005Jj-00 for simple@ietf.org; Fri, 30 May 2003 10:48:18 -0400 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEnwD25295 for ; Fri, 30 May 2003 17:49:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:49:57 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:49:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: Use of 202 response for subscription with filter (was :RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00) Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7674@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMl93Isnq2WctX1Sz+KgyocdQD9awAwnxwg To: , X-OriginalArrivalTime: 30 May 2003 14:49:57.0797 (UTC) FILETIME=[BD493550:01C326BA] X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h4UEo5B09320 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:49:57 +0300 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4UEvgB09807 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UF32B10268 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:32 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: Re: [Simple] RE: Comments on > draft-khartabil-simple-filter-funct-00 > > > > > Next comment relates to clause 3.3.4 Subscriber Interpreting > > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE > > Requests, and clause 5.4 Handling Abnormal Cases: > > > > The meaning of 200 and 202 responses to Subscribe requests is > > already defined in RFC 3265 and they relate to the state of > > the subscription I don’t think we should further extend their > > meaning to also include a meaning to the state of the filter > > criteria. It seems the server has four basic options: > > > > 1) It can accept the subscription and also accept the filter > > criteria. – 200 OK > > 2) It can accept the subscription but ignore all the filter > > criteria - 200 OK > > 3) It can reject the subscription (which also rejects the > > filter criteria) - 4xxx > > 4) It can indicate that the subscription has been > > understood, and that authorization may or may not have been > > granted. - 202 > > I think the text as it is now is ok. Some implementations of > the server might want to examine the filter after responding > to the SUBSCRIBE. A 202 in this case is needed. > > [AA] My concern is with extending the meaning of 200 OK and > 202 from that stated in RFC 3265. The text of concern is in > clause 5.2 “A "200" response indicates that the subscription > has been accepted, the user is authorized and the filter is > accepted.” AND “A "202" response also indicates that the > filter criteria have not been accepted yet.” > > [AA] IMO even if we go with the approach of rejecting the > subscription if the filter criteria is rejected we do not > need this text since the RFC 3265 wording still applies – the > subscription is either rejected or authorised or pending. If > the implementation wants to examine the filter criteria > before authorising the subscription then a 202 is appropriate > and I think this is covered in 3265 as well. If we choose to > always reject the subscription if the filter criteria is not > acceptable then all we need to state in the draft is that > rejection of the filter criteria means that the subscription > must also be rejected as you propose below. > I still think we need to spell it out in the filtering draft. What do you think Adam? /Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 11:05:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11932; Fri, 30 May 2003 11:05:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlPt-0005Rj-00; Fri, 30 May 2003 11:03:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlPs-0005Rg-00; Fri, 30 May 2003 11:03:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF03B10058; Fri, 30 May 2003 11:00:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEv6B09657 for ; Fri, 30 May 2003 10:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11462 for ; Fri, 30 May 2003 10:57:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlHt-0005Mc-00 for simple@ietf.org; Fri, 30 May 2003 10:55:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19LlHs-0005MZ-00 for simple@ietf.org; Fri, 30 May 2003 10:55:20 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEuxW29911 for ; Fri, 30 May 2003 17:56:59 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:56:58 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:56:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on draft-khartabil-simple-filter-format-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7676@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-khartabil-simple-filter-format-00 Thread-Index: AcMmB6kt0kDtZUedT/+6WodhFHmv6gAs/+yg To: , X-OriginalArrivalTime: 30 May 2003 14:56:57.0650 (UTC) FILETIME=[B789B120:01C326BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UEv6B09658 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:56:57 +0300 Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:36 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: [Simple] Comments on draft-khartabil-simple-filter-format-00 > > > > Hisham, > > I currently have just a small comment regarding > draft-khartabil-simple-filter-format-00, however I think some > of the comments against the requirements and functional > drafts may also have a consequentual impact against this draft. > > I think we need an example of the usage of the added and > removed triggers. It is not clear to me how it is envisioned > that the syntax works right now. Ok, will add. Thanks, Hisham > > > Regards > Andrew > > > _______________________________________________ > 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 mailnull@www1.ietf.org Fri May 30 11:05:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11976 for ; Fri, 30 May 2003 11:05:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UF5Nr10423 for simple-archive@odin.ietf.org; Fri, 30 May 2003 11:05:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF5NB10417 for ; Fri, 30 May 2003 11:05:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11932; Fri, 30 May 2003 11:05:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlPt-0005Rj-00; Fri, 30 May 2003 11:03:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlPs-0005Rg-00; Fri, 30 May 2003 11:03:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF03B10058; Fri, 30 May 2003 11:00:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UEv6B09657 for ; Fri, 30 May 2003 10:57:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11462 for ; Fri, 30 May 2003 10:57:00 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlHt-0005Mc-00 for simple@ietf.org; Fri, 30 May 2003 10:55:21 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19LlHs-0005MZ-00 for simple@ietf.org; Fri, 30 May 2003 10:55:20 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UEuxW29911 for ; Fri, 30 May 2003 17:56:59 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 17:56:58 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 17:56:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on draft-khartabil-simple-filter-format-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7676@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on draft-khartabil-simple-filter-format-00 Thread-Index: AcMmB6kt0kDtZUedT/+6WodhFHmv6gAs/+yg To: , X-OriginalArrivalTime: 30 May 2003 14:56:57.0650 (UTC) FILETIME=[B789B120:01C326BB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UEv6B09658 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 17:56:57 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > -----Original Message----- > From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] > Sent: Thursday, May 29, 2003 6:36 PM > To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org > Cc: AndrewAllen007@aol.com > Subject: [Simple] Comments on draft-khartabil-simple-filter-format-00 > > > > Hisham, > > I currently have just a small comment regarding > draft-khartabil-simple-filter-format-00, however I think some > of the comments against the requirements and functional > drafts may also have a consequentual impact against this draft. > > I think we need an example of the usage of the added and > removed triggers. It is not clear to me how it is envisioned > that the syntax works right now. Ok, will add. Thanks, Hisham > > > Regards > Andrew > > > _______________________________________________ > 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 May 30 11:12: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 LAA12537; Fri, 30 May 2003 11:12:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlWm-0005ct-00; Fri, 30 May 2003 11:10:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlWm-0005cq-00; Fri, 30 May 2003 11:10:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF77B10725; Fri, 30 May 2003 11:07:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF6KB10461 for ; Fri, 30 May 2003 11:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12061 for ; Fri, 30 May 2003 11:06:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlQo-0005U6-00 for simple@ietf.org; Fri, 30 May 2003 11:04:34 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19LlQn-0005Tx-00 for simple@ietf.org; Fri, 30 May 2003 11:04:33 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UF6CD06452 for ; Fri, 30 May 2003 18:06:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 18:06:12 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 18:06:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7678@esebe019.ntc.nokia.com> Thread-Topic: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMmBPByuQzpmZ1JRTu6bNWVw+o8LAAt71PA To: Cc: , X-OriginalArrivalTime: 30 May 2003 15:06:12.0567 (UTC) FILETIME=[024B4E70:01C326BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UF6KB10462 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 18:06:11 +0300 Content-Transfer-Encoding: 8bit Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, May 29, 2003 8:08 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: AndrewAllen007@aol.com; simple@ietf.org > Subject: placing filters in refreshes, was: Re: [Simple] RE: > Comments on > draft-khartabil-simple-filter-funct-00 > > > > > hisham.khartabil@nokia.com wrote: > > > > >> As I stated in my earlier email regarding the requirement draft I > >> have a concern with the replace semantics of the filter criteria > >> in the Subscribe. I am concerned that the filter criteria could > >> become quite large especially if the watcher has different filter > >> criteria for different presentities within presence lists. Do we > >> need to have every refresh subscriptions include all the filter > >> criteria for every presentity being watching everytime as our > >> goal is bandwidth efficiency between the watcher and the network? > >> I think that filter criteria will be modified by watchers a lot > >> less regularly than the period of refresh subscriptions and so it > >> is better to have some very small extra overhead when creating, > >> modifying or deleting the filter than having to include the > >> filter criteria in every refresh. I think some similar > >> functionality to the partial drafts may be the way forward here. > > > > > > As I commented earlier, I share your concern and will look into it > > before the next version of the I-D is released. > > I have an idea here. > > THe idea is that, instead of sending the filter, the > SUBSCRIBE refresh > includes a hash of the filter as the body of the request (with a > content-type along the lines of filter-hash or something). The server > checks the hash to see if it maps against any existing filter > that has > been used in this dialog (and indeed, part of different dialogs too - > would allow for sharing of filters). If so, the server acts > as if that > filter was in the body of the SUBSCRIBE. If not, it rejects teh > request and the client can re-try with the full filter. > > Basically, this is caching of filter documents, using a hash of the > document as a reference to a cache entry. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 mailnull@www1.ietf.org Fri May 30 11:12:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12562 for ; Fri, 30 May 2003 11:12:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UFCQb11624 for simple-archive@odin.ietf.org; Fri, 30 May 2003 11:12:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFCQB11621 for ; Fri, 30 May 2003 11:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12537; Fri, 30 May 2003 11:12:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlWm-0005ct-00; Fri, 30 May 2003 11:10:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LlWm-0005cq-00; Fri, 30 May 2003 11:10:44 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF77B10725; Fri, 30 May 2003 11:07:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UF6KB10461 for ; Fri, 30 May 2003 11:06:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12061 for ; Fri, 30 May 2003 11:06:14 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlQo-0005U6-00 for simple@ietf.org; Fri, 30 May 2003 11:04:34 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 19LlQn-0005Tx-00 for simple@ietf.org; Fri, 30 May 2003 11:04:33 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4UF6CD06452 for ; Fri, 30 May 2003 18:06:12 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 May 2003 18:06:12 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 30 May 2003 18:06:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7678@esebe019.ntc.nokia.com> Thread-Topic: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 Thread-Index: AcMmBPByuQzpmZ1JRTu6bNWVw+o8LAAt71PA To: Cc: , X-OriginalArrivalTime: 30 May 2003 15:06:12.0567 (UTC) FILETIME=[024B4E70:01C326BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4UF6KB10462 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 18:06:11 +0300 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id. Regards, Hisham > -----Original Message----- > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thursday, May 29, 2003 8:08 PM > To: Khartabil Hisham (NMP/Helsinki) > Cc: AndrewAllen007@aol.com; simple@ietf.org > Subject: placing filters in refreshes, was: Re: [Simple] RE: > Comments on > draft-khartabil-simple-filter-funct-00 > > > > > hisham.khartabil@nokia.com wrote: > > > > >> As I stated in my earlier email regarding the requirement draft I > >> have a concern with the replace semantics of the filter criteria > >> in the Subscribe. I am concerned that the filter criteria could > >> become quite large especially if the watcher has different filter > >> criteria for different presentities within presence lists. Do we > >> need to have every refresh subscriptions include all the filter > >> criteria for every presentity being watching everytime as our > >> goal is bandwidth efficiency between the watcher and the network? > >> I think that filter criteria will be modified by watchers a lot > >> less regularly than the period of refresh subscriptions and so it > >> is better to have some very small extra overhead when creating, > >> modifying or deleting the filter than having to include the > >> filter criteria in every refresh. I think some similar > >> functionality to the partial drafts may be the way forward here. > > > > > > As I commented earlier, I share your concern and will look into it > > before the next version of the I-D is released. > > I have an idea here. > > THe idea is that, instead of sending the filter, the > SUBSCRIBE refresh > includes a hash of the filter as the body of the request (with a > content-type along the lines of filter-hash or something). The server > checks the hash to see if it maps against any existing filter > that has > been used in this dialog (and indeed, part of different dialogs too - > would allow for sharing of filters). If so, the server acts > as if that > filter was in the body of the SUBSCRIBE. If not, it rejects teh > request and the client can re-try with the full filter. > > Basically, this is caching of filter documents, using a hash of the > document as a reference to a cache entry. > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist 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 May 30 11:36:38 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13529; Fri, 30 May 2003 11:36:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LluE-0005or-00; Fri, 30 May 2003 11:34:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LluE-0005oo-00; Fri, 30 May 2003 11:34:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFVGB12679; Fri, 30 May 2003 11:31:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFUsB12551 for ; Fri, 30 May 2003 11:30:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13221 for ; Fri, 30 May 2003 11:30:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lloe-0005lB-00 for simple@ietf.org; Fri, 30 May 2003 11:29:12 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19Llod-0005l6-00 for simple@ietf.org; Fri, 30 May 2003 11:29:11 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UFTxx16395; Fri, 30 May 2003 10:30:00 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 10:30:00 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E011D81B7@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Ben Campbell'" , Jonathan Rosenberg Cc: Avshalom Houri , Paul Kyzivat , Simple WG Subject: RE: [Simple] PUBLISH and REGISTER relationship MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326C0.54813F9E" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 10:29:59 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C326C0.54813F9E Content-Type: text/plain; charset="iso-8859-1" Agree whole-heartedly. Especially with the current discussion regarding RPIDs (which to me seems to somewhat try to involve registration type data with the presence document)... The presence document is a portrait of an amalgamation of information from multiple sources, but PUBLISH does not try to replace these mechanisms, but to simply provide yet another voice as to what should appear in the presence document which is not easily determinable via the currently available mechanisms within SIP. Regards, Brian -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Friday, May 30, 2003 10:42 AM To: Jonathan Rosenberg Cc: Avshalom Houri; Paul Kyzivat; Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg wrote: > The interim has motivated me to respond to this somewhat old thread. > > I think there is a distinction, and it lies with the model of how > presence works. > > In my mind, there is an existing universe of data about users. This > data is embedded in many, many places - in HLRs, in VLRs, in > registrars, in corporate databases, in cell phones, in PBXs, etc. This > data has meaning within the systems in which it resides, and there are > protocols within those systems for manipulation of it. Protocols like > LDAP, SIP REGISTER, SS7, etc. > > Separate from that is a presence system. The presence system provides > a "front end" for this data below, allowing interested parties to > subscribe to it, and based on authorization policies, receive > notifications to it. PUBLISH is an interface between these existing > systems and the presence system, providing a standardized way to move > information between them. > > However, PUBLISH in no way replaces any of the above protocols. > > So, in the specific case of SIP, the existing system is the registrar. > It has state, manipulated by REGISTER, and consumed by proxies for > call routing. Separately, ontop of this system, lies a presence > server. The registrar would push registration state into the presence > server using PUBLISH. > > So, I would argue that a PUBLISH has no impact on registration state, > unless there is some very odd, domain-specific policy that decides to > make it that way. This isn't a PUBLISH specific issue. One can imagine > that an enterprise has a web system where users login to the corporate > website when they come to work. This login could trigger a sip > registration to be created. We dont disallow this kind of thing, but > there is no expectation that it exists as a general rule. > I will go further and say that there is no SIMPLE requirement that REGISTER and PUBLISH are related in any way. REGISTER _might_ affect presence state in the way you mention above, and probably will for most systems. But if someone builds a system in which it does not, that system is not in violation of any SIMPLE principle. Just because it is extremely useful does not make it required. > -Jonathan R. > > Ben Campbell wrote: > > On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: > > > >>If we were creating the SIP protocol today I am not sure that both > >>REGISTER and PUBLISH would have been > >>created. We would have created only one of them. Now we have both several > >>questions may arise: > > > > > > I agree we may not have gone the same route if we were inventing from > > scratch. That is, of course, true of many things. However, REGISTER and > > PUBLISH have different purposes. REGISTER puts rendezvous info into the > > SIP network infrastructure--sort of a higer-layer route generation. > > PUBLISH carries presence info to be distributed to watchers. Now, that > > presence info _might_ be a superset of the rendezvous info, but it > > doesn't have to be. > > > > > >>* Is it "legal" for a system to add the contacts it got through PUBLISH to > >>the registrar? > > > > > > Assuming you mean in the broader sense of a location service, sure. It's > > legal to put contacts into a location service from _any_ source. It is > > up to the implementer to decide what sources make sense for his > > implementation. (This particular case might not be a good idea, but the > > protocol does not categorically rule out bad policy decisions.) > > > > > >> Someone would like to reveal some contacts only to the users that can > >>see her/his presence. > > > > > > Sure. But as above, don't equate policy with protocol rules. There are > > many policies a network could follow that would allow this bit of > > choice. > > > > > >>* Probably the same question from a different angle: What should be the > >>awareness of the user > >> to the system behavior. The user may think that if the PUBLISH have > >>expired he/she is no longer > >> available online while the system may use REGISTER in order to consider > >>the user as online. > > > > > > I don't think we have fully defined what it means for a publication to > > expire. I would suggest it meanst that the watcher should consider the > > presence state to be indeterminant. Indeterminant is not the same thing > > as off-line. > > > > I don't see why presence expiration should necessarily imply anything > > about registration state. Certainly, there is no protocol rule that > > prevents an AoR from working, even if presence state indicates the user > > is offline. If a user wants to make sure this does not happen, he could > > simply set the same expiration for registered contacts as he does for > > published presence state. > > > > Personally, I don't think we can pre-define any relationship between > > REGISTER and PUBLISH. Such things are a matter of local policy. The > > architecture draft may suggest some possible useful policies, but should > > not preclude creativity in creating totally different policies. > > > > > > > >>Avshalom > >> > >> > >> > >> > >> > >>Paul Kyzivat > >>07/05/2003 21:28 > >> > >>To > >>Ben Campbell > >>cc > >>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG > >>Subject > >>Re: [Simple] PUBLISH and REGISTER relationship > >> > >> > >> > >> > >> > >> > >>I'm assuming you are questioning the relationship between requests that > >>start out somethin like: > >> > >> REGISTER sip:example.com > >> To: sip:foo@example.com > >> ... > >> > >>and > >> > >> PUBLISH sip:foo@example.com > >> To: sip:foo@example.com > >> ... > >> > >>If so, I think there is some probable precedence of the REGISTER over > >>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for > >>address sip:foo@example.com. It is not routed according to the prior set > >>of registered contacts for that address. > >> > >>OTOH, the PUBLISH, at least in principle, is just an ordinary message, > >>and is routed based on the registered contacts, plus local policy of the > >>proxy/registrar. > >> > >>So, the REGISTER *could* have been installing a contact for the presence > >>server itself. In that case, prior to the register the PUBLISH might > >>have failed, whereas after it might succeed. I don't think the converse > >>is a likely scenario. (That before the publish the register would fail, > >>but after the register would succeed.) > >> > >>I do agree that there are similarities between REGISTER and PUBLISH. I > >>can imagine a system that supports PUBLISH and not REGISTER, and does > >>all routing based on presence, using the contact addresses in presence > >>tuples. That would be an unusual sip system today, though it may be less > >>so in the future. > >> > >>I also agree with Ben that there is plenty of opportunity for local > >>policy to determine what happens here. I expect there will be plenty of > >>systems where the registrar, presence server, and proxy are all bundled > >>together and cooperate via local configuration. > >> > >> Paul > >> > >>Ben Campbell wrote: > >> > >>>I think that is entirely a question of local policy. There is no > >>>protocol requirement for the two operations to be linked in any way, but > >>>a given service provider might choose to do so. > >>> > >>>If you _do_ link them, you are making assumptions about a relationship > >>>between the device doing the publishing and the device doing the > >>>registering that may or may not exist. > >>> > >>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: > >>> > >>> > >>>>In a system that has both a registrar and a presence server what should > >> > >>be > >> > >>>>the relationships between > >>>>REGISTER and PUBLISH? > >>>> > >>>>* Should a REGISTER make the user on-line even though PUBLISH was not > >> > >>sent > >> > >>>>yet? > >>>>* Should PUBLISH be considered as a login to the system as REGISTER? > >>>> > >>>>To some extent it seems that PUBLISH and REGISTER have a similar > >>>>functionality but one is for the registrar > >>>>while the other is for the presence server. > >>>> > >>>>Avshalom > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C326C0.54813F9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] PUBLISH and REGISTER relationship

Agree whole-heartedly. Especially with the current = discussion regarding RPIDs (which to me seems to somewhat try to = involve registration type data with the presence = document)...

The presence document is a portrait of an = amalgamation of information from multiple sources, but PUBLISH does not = try to replace these mechanisms, but to simply provide yet another = voice as to what should appear in the presence document which is not = easily determinable via the currently available mechanisms within = SIP.

Regards,

Brian

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.c= om]
Sent: Friday, May 30, 2003 10:42 AM
To: Jonathan Rosenberg
Cc: Avshalom Houri; Paul Kyzivat; Simple WG
Subject: Re: [Simple] PUBLISH and REGISTER = relationship


On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg = wrote:
> The interim has motivated me to respond to this = somewhat old thread.
>
> I think there is a distinction, and it lies = with the model of how
> presence works.
>
> In my mind, there is an existing universe of = data about users. This
> data is embedded in many, many places - in = HLRs, in VLRs, in
> registrars, in corporate databases, in cell = phones, in PBXs, etc. This
> data has meaning within the systems in which it = resides, and there are
> protocols within those systems for manipulation = of it. Protocols like
> LDAP, SIP REGISTER, SS7, etc.
>
> Separate from that is a presence system. The = presence system provides
> a "front end" for this data below, = allowing interested parties to
> subscribe to it, and based on authorization = policies, receive
> notifications to it. PUBLISH is an interface = between these existing
> systems and the presence system, providing a = standardized way to move
> information between them.
>
> However, PUBLISH in no way replaces any of the = above protocols.
>
> So, in the specific case of SIP, the existing = system is the registrar.
> It has state, manipulated by REGISTER, and = consumed by proxies for
> call routing. Separately, ontop of this system, = lies a presence
> server. The registrar would push registration = state into the presence
> server using PUBLISH.
>
> So, I would argue that a PUBLISH has no impact = on registration state,
> unless there is some very odd, domain-specific = policy that decides to
> make it that way. This isn't a PUBLISH specific = issue. One can imagine
> that an enterprise has a web system where users = login to the corporate
> website when they come to work. This login = could trigger a sip
> registration to be created. We dont disallow = this kind of thing, but
> there is no expectation that it exists as a = general rule.
>

I will go further and say that there is no SIMPLE = requirement that
REGISTER and PUBLISH are related in any way. = REGISTER _might_ affect
presence state in the way you mention above, and = probably will for most
systems. But if someone builds a system in which it = does not, that
system is not in violation of any SIMPLE principle. = Just because it is
extremely useful does not make it required.



> -Jonathan R.
>
> Ben Campbell wrote:
> > On Wed, 2003-05-14 at 07:25, Avshalom = Houri wrote:
> >
> >>If we were creating the SIP protocol = today I am not sure that both
> >>REGISTER and PUBLISH would have = been
> >>created. We would have created only one = of them. Now we have both several
> >>questions may arise:
> >
> >
> > I agree we may not have gone the same = route if we were inventing from
> > scratch. That is, of course, true of many = things. However, REGISTER and
> > PUBLISH have different purposes. REGISTER = puts rendezvous info into the
> > SIP network infrastructure--sort of a = higer-layer route generation.
> > PUBLISH carries presence info to be = distributed to watchers. Now, that
> > presence info _might_ be a superset of the = rendezvous info, but it
> > doesn't have to be.
> >
> >
> >>* Is it "legal" for a system = to add the contacts it got through PUBLISH to
> >>the registrar?
> >
> >
> > Assuming you mean in the broader sense of = a location service, sure. It's
> > legal to put contacts into a location = service from _any_ source. It is
> > up to the implementer to decide what = sources make sense for his
> > implementation. (This particular case = might not be a good idea, but the
> > protocol does not categorically rule out = bad policy decisions.)
> >
> >
> >>  Someone would like to reveal = some contacts only to the users that can
> >>see her/his presence.
> >
> >
> > Sure. But as above, don't equate policy = with protocol rules. There are
> > many policies a network could follow that = would allow this bit of
> > choice.
> >
> >
> >>* Probably the same question from a = different angle: What should be the
> >>awareness of the user
> >>  to the system behavior. The user = may think that if the PUBLISH have
> >>expired he/she is no longer
> >>  available online while the = system may use REGISTER in order to consider
> >>the user as online.
> >
> >
> > I don't think we have fully defined what = it means for a publication to
> > expire. I would suggest it meanst that the = watcher should consider the
> > presence state to be indeterminant. = Indeterminant is not the same thing
> > as off-line.
> >
> > I don't see why presence expiration should = necessarily imply anything
> > about registration state. Certainly, there = is no protocol rule that
> > prevents an AoR from working, even if = presence state indicates the user
> > is offline. If a user wants to make sure = this does not happen, he could
> > simply set the same expiration for = registered contacts as he does for
> > published presence state.
> >
> > Personally, I don't think we can = pre-define any relationship between
> > REGISTER and PUBLISH. Such things are a = matter of local policy. The
> > architecture draft may suggest some = possible useful policies, but should
> > not preclude creativity in creating = totally different policies.
> >
> >
> >
> >>Avshalom
> >>
> >>
> >>
> >>
> >>
> >>Paul Kyzivat <pkyzivat@cisco.com> =
> >>07/05/2003 21:28
> >>
> >>To
> >>Ben Campbell = <bcampbell@dynamicsoft.com>
> >>cc
> >>Avshalom Houri/Haifa/IBM@IBMIL, Simple = WG <simple@ietf.org>
> >>Subject
> >>Re: [Simple] PUBLISH and REGISTER = relationship
> >>
> >>
> >>
> >>
> >>
> >>
> >>I'm assuming you are questioning the = relationship between requests that
> >>start out somethin like:
> >>
> = >>          &nbs= p;      REGISTER sip:example.com
> = >>          &nbs= p;      To: sip:foo@example.com
> = >>          &nbs= p;      ...
> >>
> >>and
> >>
> = >>          &nbs= p;      PUBLISH sip:foo@example.com
> = >>          &nbs= p;      To: sip:foo@example.com
> = >>          &nbs= p;      ...
> >>
> >>If so, I think there is some probable = precedence of the REGISTER over
> >>the SUBSCRIBE. The REGISTER affects the = candidate set of contacts for
> >>address sip:foo@example.com. It is not = routed according to the prior set
> >>of registered contacts for that = address.
> >>
> >>OTOH, the PUBLISH, at least in = principle, is just an ordinary message,
> >>and is routed based on the registered = contacts, plus local policy of the
> >>proxy/registrar.
> >>
> >>So, the REGISTER *could* have been = installing a contact for the presence
> >>server itself. In that case, prior to = the register the PUBLISH might
> >>have failed, whereas after it might = succeed. I don't think the converse
> >>is a likely scenario. (That before the = publish the register would fail,
> >>but after the register would = succeed.)
> >>
> >>I do agree that there are similarities = between REGISTER and PUBLISH. I
> >>can imagine a system that supports = PUBLISH and not REGISTER, and does
> >>all routing based on presence, using = the contact addresses in presence
> >>tuples. That would be an unusual sip = system today, though it may be less
> >>so in the future.
> >>
> >>I also agree with Ben that there is = plenty of opportunity for local
> >>policy to determine what happens here. = I expect there will be plenty of
> >>systems where the registrar, presence = server, and proxy are all bundled
> >>together and cooperate via local = configuration.
> >>
> = >>          &nbs= p;      Paul
> >>
> >>Ben Campbell wrote:
> >>
> >>>I think that is entirely a question = of local policy. There is no
> >>>protocol requirement for the two = operations to be linked in any way, but
> >>>a given service provider might = choose to do so.
> >>>
> >>>If you _do_ link them, you are = making assumptions about a relationship
> >>>between the device doing the = publishing and the device doing the
> >>>registering that may or may not = exist.
> >>>
> >>>On Tue, 2003-05-06 at 00:21, = Avshalom Houri wrote:
> >>>
> >>>
> >>>>In a system that has both a = registrar and a presence server what should
> >>
> >>be
> >>
> >>>>the relationships = between
> >>>>REGISTER and PUBLISH?
> >>>>
> >>>>* Should a REGISTER make the = user on-line even though PUBLISH was not
> >>
> >>sent
> >>
> >>>>yet?
> >>>>* Should PUBLISH be considered = as a login to the system as REGISTER?
> >>>>
> >>>>To some extent it seems that = PUBLISH and REGISTER have a similar
> >>>>functionality but one is for = the registrar
> >>>>while the other is for the = presence server.
> >>>>
> >>>>Avshalom
> >>>>
> >>>>
> = >>>>_______________________________________________
> >>>>Simple mailing list
> >>>>Simple@ietf.org
> >>>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>>
> = >>>_______________________________________________
> >>>Simple mailing list
> >>>Simple@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>
> >
> > = _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >

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

------_=_NextPart_001_01C326C0.54813F9E-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 11:37:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13554 for ; Fri, 30 May 2003 11:37:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UFafX12979 for simple-archive@odin.ietf.org; Fri, 30 May 2003 11:36:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFafB12976 for ; Fri, 30 May 2003 11:36:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13529; Fri, 30 May 2003 11:36:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LluE-0005or-00; Fri, 30 May 2003 11:34:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LluE-0005oo-00; Fri, 30 May 2003 11:34:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFVGB12679; Fri, 30 May 2003 11:31:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFUsB12551 for ; Fri, 30 May 2003 11:30:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13221 for ; Fri, 30 May 2003 11:30:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lloe-0005lB-00 for simple@ietf.org; Fri, 30 May 2003 11:29:12 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19Llod-0005l6-00 for simple@ietf.org; Fri, 30 May 2003 11:29:11 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4UFTxx16395; Fri, 30 May 2003 10:30:00 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 May 2003 10:30:00 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E011D81B7@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "'Ben Campbell'" , Jonathan Rosenberg Cc: Avshalom Houri , Paul Kyzivat , Simple WG Subject: RE: [Simple] PUBLISH and REGISTER relationship MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C326C0.54813F9E" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.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, 30 May 2003 10:29:59 -0500 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C326C0.54813F9E Content-Type: text/plain; charset="iso-8859-1" Agree whole-heartedly. Especially with the current discussion regarding RPIDs (which to me seems to somewhat try to involve registration type data with the presence document)... The presence document is a portrait of an amalgamation of information from multiple sources, but PUBLISH does not try to replace these mechanisms, but to simply provide yet another voice as to what should appear in the presence document which is not easily determinable via the currently available mechanisms within SIP. Regards, Brian -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Friday, May 30, 2003 10:42 AM To: Jonathan Rosenberg Cc: Avshalom Houri; Paul Kyzivat; Simple WG Subject: Re: [Simple] PUBLISH and REGISTER relationship On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg wrote: > The interim has motivated me to respond to this somewhat old thread. > > I think there is a distinction, and it lies with the model of how > presence works. > > In my mind, there is an existing universe of data about users. This > data is embedded in many, many places - in HLRs, in VLRs, in > registrars, in corporate databases, in cell phones, in PBXs, etc. This > data has meaning within the systems in which it resides, and there are > protocols within those systems for manipulation of it. Protocols like > LDAP, SIP REGISTER, SS7, etc. > > Separate from that is a presence system. The presence system provides > a "front end" for this data below, allowing interested parties to > subscribe to it, and based on authorization policies, receive > notifications to it. PUBLISH is an interface between these existing > systems and the presence system, providing a standardized way to move > information between them. > > However, PUBLISH in no way replaces any of the above protocols. > > So, in the specific case of SIP, the existing system is the registrar. > It has state, manipulated by REGISTER, and consumed by proxies for > call routing. Separately, ontop of this system, lies a presence > server. The registrar would push registration state into the presence > server using PUBLISH. > > So, I would argue that a PUBLISH has no impact on registration state, > unless there is some very odd, domain-specific policy that decides to > make it that way. This isn't a PUBLISH specific issue. One can imagine > that an enterprise has a web system where users login to the corporate > website when they come to work. This login could trigger a sip > registration to be created. We dont disallow this kind of thing, but > there is no expectation that it exists as a general rule. > I will go further and say that there is no SIMPLE requirement that REGISTER and PUBLISH are related in any way. REGISTER _might_ affect presence state in the way you mention above, and probably will for most systems. But if someone builds a system in which it does not, that system is not in violation of any SIMPLE principle. Just because it is extremely useful does not make it required. > -Jonathan R. > > Ben Campbell wrote: > > On Wed, 2003-05-14 at 07:25, Avshalom Houri wrote: > > > >>If we were creating the SIP protocol today I am not sure that both > >>REGISTER and PUBLISH would have been > >>created. We would have created only one of them. Now we have both several > >>questions may arise: > > > > > > I agree we may not have gone the same route if we were inventing from > > scratch. That is, of course, true of many things. However, REGISTER and > > PUBLISH have different purposes. REGISTER puts rendezvous info into the > > SIP network infrastructure--sort of a higer-layer route generation. > > PUBLISH carries presence info to be distributed to watchers. Now, that > > presence info _might_ be a superset of the rendezvous info, but it > > doesn't have to be. > > > > > >>* Is it "legal" for a system to add the contacts it got through PUBLISH to > >>the registrar? > > > > > > Assuming you mean in the broader sense of a location service, sure. It's > > legal to put contacts into a location service from _any_ source. It is > > up to the implementer to decide what sources make sense for his > > implementation. (This particular case might not be a good idea, but the > > protocol does not categorically rule out bad policy decisions.) > > > > > >> Someone would like to reveal some contacts only to the users that can > >>see her/his presence. > > > > > > Sure. But as above, don't equate policy with protocol rules. There are > > many policies a network could follow that would allow this bit of > > choice. > > > > > >>* Probably the same question from a different angle: What should be the > >>awareness of the user > >> to the system behavior. The user may think that if the PUBLISH have > >>expired he/she is no longer > >> available online while the system may use REGISTER in order to consider > >>the user as online. > > > > > > I don't think we have fully defined what it means for a publication to > > expire. I would suggest it meanst that the watcher should consider the > > presence state to be indeterminant. Indeterminant is not the same thing > > as off-line. > > > > I don't see why presence expiration should necessarily imply anything > > about registration state. Certainly, there is no protocol rule that > > prevents an AoR from working, even if presence state indicates the user > > is offline. If a user wants to make sure this does not happen, he could > > simply set the same expiration for registered contacts as he does for > > published presence state. > > > > Personally, I don't think we can pre-define any relationship between > > REGISTER and PUBLISH. Such things are a matter of local policy. The > > architecture draft may suggest some possible useful policies, but should > > not preclude creativity in creating totally different policies. > > > > > > > >>Avshalom > >> > >> > >> > >> > >> > >>Paul Kyzivat > >>07/05/2003 21:28 > >> > >>To > >>Ben Campbell > >>cc > >>Avshalom Houri/Haifa/IBM@IBMIL, Simple WG > >>Subject > >>Re: [Simple] PUBLISH and REGISTER relationship > >> > >> > >> > >> > >> > >> > >>I'm assuming you are questioning the relationship between requests that > >>start out somethin like: > >> > >> REGISTER sip:example.com > >> To: sip:foo@example.com > >> ... > >> > >>and > >> > >> PUBLISH sip:foo@example.com > >> To: sip:foo@example.com > >> ... > >> > >>If so, I think there is some probable precedence of the REGISTER over > >>the SUBSCRIBE. The REGISTER affects the candidate set of contacts for > >>address sip:foo@example.com. It is not routed according to the prior set > >>of registered contacts for that address. > >> > >>OTOH, the PUBLISH, at least in principle, is just an ordinary message, > >>and is routed based on the registered contacts, plus local policy of the > >>proxy/registrar. > >> > >>So, the REGISTER *could* have been installing a contact for the presence > >>server itself. In that case, prior to the register the PUBLISH might > >>have failed, whereas after it might succeed. I don't think the converse > >>is a likely scenario. (That before the publish the register would fail, > >>but after the register would succeed.) > >> > >>I do agree that there are similarities between REGISTER and PUBLISH. I > >>can imagine a system that supports PUBLISH and not REGISTER, and does > >>all routing based on presence, using the contact addresses in presence > >>tuples. That would be an unusual sip system today, though it may be less > >>so in the future. > >> > >>I also agree with Ben that there is plenty of opportunity for local > >>policy to determine what happens here. I expect there will be plenty of > >>systems where the registrar, presence server, and proxy are all bundled > >>together and cooperate via local configuration. > >> > >> Paul > >> > >>Ben Campbell wrote: > >> > >>>I think that is entirely a question of local policy. There is no > >>>protocol requirement for the two operations to be linked in any way, but > >>>a given service provider might choose to do so. > >>> > >>>If you _do_ link them, you are making assumptions about a relationship > >>>between the device doing the publishing and the device doing the > >>>registering that may or may not exist. > >>> > >>>On Tue, 2003-05-06 at 00:21, Avshalom Houri wrote: > >>> > >>> > >>>>In a system that has both a registrar and a presence server what should > >> > >>be > >> > >>>>the relationships between > >>>>REGISTER and PUBLISH? > >>>> > >>>>* Should a REGISTER make the user on-line even though PUBLISH was not > >> > >>sent > >> > >>>>yet? > >>>>* Should PUBLISH be considered as a login to the system as REGISTER? > >>>> > >>>>To some extent it seems that PUBLISH and REGISTER have a similar > >>>>functionality but one is for the registrar > >>>>while the other is for the presence server. > >>>> > >>>>Avshalom > >>>> > >>>> > >>>>_______________________________________________ > >>>>Simple mailing list > >>>>Simple@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C326C0.54813F9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] PUBLISH and REGISTER relationship

Agree whole-heartedly. Especially with the current = discussion regarding RPIDs (which to me seems to somewhat try to = involve registration type data with the presence = document)...

The presence document is a portrait of an = amalgamation of information from multiple sources, but PUBLISH does not = try to replace these mechanisms, but to simply provide yet another = voice as to what should appear in the presence document which is not = easily determinable via the currently available mechanisms within = SIP.

Regards,

Brian

-----Original Message-----
From: Ben Campbell [mailto:bcampbell@dynamicsoft.c= om]
Sent: Friday, May 30, 2003 10:42 AM
To: Jonathan Rosenberg
Cc: Avshalom Houri; Paul Kyzivat; Simple WG
Subject: Re: [Simple] PUBLISH and REGISTER = relationship


On Fri, 2003-05-30 at 09:31, Jonathan Rosenberg = wrote:
> The interim has motivated me to respond to this = somewhat old thread.
>
> I think there is a distinction, and it lies = with the model of how
> presence works.
>
> In my mind, there is an existing universe of = data about users. This
> data is embedded in many, many places - in = HLRs, in VLRs, in
> registrars, in corporate databases, in cell = phones, in PBXs, etc. This
> data has meaning within the systems in which it = resides, and there are
> protocols within those systems for manipulation = of it. Protocols like
> LDAP, SIP REGISTER, SS7, etc.
>
> Separate from that is a presence system. The = presence system provides
> a "front end" for this data below, = allowing interested parties to
> subscribe to it, and based on authorization = policies, receive
> notifications to it. PUBLISH is an interface = between these existing
> systems and the presence system, providing a = standardized way to move
> information between them.
>
> However, PUBLISH in no way replaces any of the = above protocols.
>
> So, in the specific case of SIP, the existing = system is the registrar.
> It has state, manipulated by REGISTER, and = consumed by proxies for
> call routing. Separately, ontop of this system, = lies a presence
> server. The registrar would push registration = state into the presence
> server using PUBLISH.
>
> So, I would argue that a PUBLISH has no impact = on registration state,
> unless there is some very odd, domain-specific = policy that decides to
> make it that way. This isn't a PUBLISH specific = issue. One can imagine
> that an enterprise has a web system where users = login to the corporate
> website when they come to work. This login = could trigger a sip
> registration to be created. We dont disallow = this kind of thing, but
> there is no expectation that it exists as a = general rule.
>

I will go further and say that there is no SIMPLE = requirement that
REGISTER and PUBLISH are related in any way. = REGISTER _might_ affect
presence state in the way you mention above, and = probably will for most
systems. But if someone builds a system in which it = does not, that
system is not in violation of any SIMPLE principle. = Just because it is
extremely useful does not make it required.



> -Jonathan R.
>
> Ben Campbell wrote:
> > On Wed, 2003-05-14 at 07:25, Avshalom = Houri wrote:
> >
> >>If we were creating the SIP protocol = today I am not sure that both
> >>REGISTER and PUBLISH would have = been
> >>created. We would have created only one = of them. Now we have both several
> >>questions may arise:
> >
> >
> > I agree we may not have gone the same = route if we were inventing from
> > scratch. That is, of course, true of many = things. However, REGISTER and
> > PUBLISH have different purposes. REGISTER = puts rendezvous info into the
> > SIP network infrastructure--sort of a = higer-layer route generation.
> > PUBLISH carries presence info to be = distributed to watchers. Now, that
> > presence info _might_ be a superset of the = rendezvous info, but it
> > doesn't have to be.
> >
> >
> >>* Is it "legal" for a system = to add the contacts it got through PUBLISH to
> >>the registrar?
> >
> >
> > Assuming you mean in the broader sense of = a location service, sure. It's
> > legal to put contacts into a location = service from _any_ source. It is
> > up to the implementer to decide what = sources make sense for his
> > implementation. (This particular case = might not be a good idea, but the
> > protocol does not categorically rule out = bad policy decisions.)
> >
> >
> >>  Someone would like to reveal = some contacts only to the users that can
> >>see her/his presence.
> >
> >
> > Sure. But as above, don't equate policy = with protocol rules. There are
> > many policies a network could follow that = would allow this bit of
> > choice.
> >
> >
> >>* Probably the same question from a = different angle: What should be the
> >>awareness of the user
> >>  to the system behavior. The user = may think that if the PUBLISH have
> >>expired he/she is no longer
> >>  available online while the = system may use REGISTER in order to consider
> >>the user as online.
> >
> >
> > I don't think we have fully defined what = it means for a publication to
> > expire. I would suggest it meanst that the = watcher should consider the
> > presence state to be indeterminant. = Indeterminant is not the same thing
> > as off-line.
> >
> > I don't see why presence expiration should = necessarily imply anything
> > about registration state. Certainly, there = is no protocol rule that
> > prevents an AoR from working, even if = presence state indicates the user
> > is offline. If a user wants to make sure = this does not happen, he could
> > simply set the same expiration for = registered contacts as he does for
> > published presence state.
> >
> > Personally, I don't think we can = pre-define any relationship between
> > REGISTER and PUBLISH. Such things are a = matter of local policy. The
> > architecture draft may suggest some = possible useful policies, but should
> > not preclude creativity in creating = totally different policies.
> >
> >
> >
> >>Avshalom
> >>
> >>
> >>
> >>
> >>
> >>Paul Kyzivat <pkyzivat@cisco.com> =
> >>07/05/2003 21:28
> >>
> >>To
> >>Ben Campbell = <bcampbell@dynamicsoft.com>
> >>cc
> >>Avshalom Houri/Haifa/IBM@IBMIL, Simple = WG <simple@ietf.org>
> >>Subject
> >>Re: [Simple] PUBLISH and REGISTER = relationship
> >>
> >>
> >>
> >>
> >>
> >>
> >>I'm assuming you are questioning the = relationship between requests that
> >>start out somethin like:
> >>
> = >>          &nbs= p;      REGISTER sip:example.com
> = >>          &nbs= p;      To: sip:foo@example.com
> = >>          &nbs= p;      ...
> >>
> >>and
> >>
> = >>          &nbs= p;      PUBLISH sip:foo@example.com
> = >>          &nbs= p;      To: sip:foo@example.com
> = >>          &nbs= p;      ...
> >>
> >>If so, I think there is some probable = precedence of the REGISTER over
> >>the SUBSCRIBE. The REGISTER affects the = candidate set of contacts for
> >>address sip:foo@example.com. It is not = routed according to the prior set
> >>of registered contacts for that = address.
> >>
> >>OTOH, the PUBLISH, at least in = principle, is just an ordinary message,
> >>and is routed based on the registered = contacts, plus local policy of the
> >>proxy/registrar.
> >>
> >>So, the REGISTER *could* have been = installing a contact for the presence
> >>server itself. In that case, prior to = the register the PUBLISH might
> >>have failed, whereas after it might = succeed. I don't think the converse
> >>is a likely scenario. (That before the = publish the register would fail,
> >>but after the register would = succeed.)
> >>
> >>I do agree that there are similarities = between REGISTER and PUBLISH. I
> >>can imagine a system that supports = PUBLISH and not REGISTER, and does
> >>all routing based on presence, using = the contact addresses in presence
> >>tuples. That would be an unusual sip = system today, though it may be less
> >>so in the future.
> >>
> >>I also agree with Ben that there is = plenty of opportunity for local
> >>policy to determine what happens here. = I expect there will be plenty of
> >>systems where the registrar, presence = server, and proxy are all bundled
> >>together and cooperate via local = configuration.
> >>
> = >>          &nbs= p;      Paul
> >>
> >>Ben Campbell wrote:
> >>
> >>>I think that is entirely a question = of local policy. There is no
> >>>protocol requirement for the two = operations to be linked in any way, but
> >>>a given service provider might = choose to do so.
> >>>
> >>>If you _do_ link them, you are = making assumptions about a relationship
> >>>between the device doing the = publishing and the device doing the
> >>>registering that may or may not = exist.
> >>>
> >>>On Tue, 2003-05-06 at 00:21, = Avshalom Houri wrote:
> >>>
> >>>
> >>>>In a system that has both a = registrar and a presence server what should
> >>
> >>be
> >>
> >>>>the relationships = between
> >>>>REGISTER and PUBLISH?
> >>>>
> >>>>* Should a REGISTER make the = user on-line even though PUBLISH was not
> >>
> >>sent
> >>
> >>>>yet?
> >>>>* Should PUBLISH be considered = as a login to the system as REGISTER?
> >>>>
> >>>>To some extent it seems that = PUBLISH and REGISTER have a similar
> >>>>functionality but one is for = the registrar
> >>>>while the other is for the = presence server.
> >>>>
> >>>>Avshalom
> >>>>
> >>>>
> = >>>>_______________________________________________
> >>>>Simple mailing list
> >>>>Simple@ietf.org
> >>>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>>
> = >>>_______________________________________________
> >>>Simple mailing list
> >>>Simple@ietf.org
> >>>https://www1.ietf.org/mailman/listinfo/simple
> >>>
> >>
> >
> > = _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >

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

------_=_NextPart_001_01C326C0.54813F9E-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 16:13: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 QAA25943; Fri, 30 May 2003 16:13:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LqEK-0000xW-00; Fri, 30 May 2003 16:12:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LqEK-0000xR-00; Fri, 30 May 2003 16:12:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UK8LB01593; Fri, 30 May 2003 16:08:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UK7OB01249 for ; Fri, 30 May 2003 16:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25757 for ; Fri, 30 May 2003 16:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lq8E-0000uq-00 for simple@ietf.org; Fri, 30 May 2003 16:05:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lq8D-0000ua-00 for simple@ietf.org; Fri, 30 May 2003 16:05:41 -0400 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 h4UK6o610045 for ; Fri, 30 May 2003 15:06:51 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054325208.935.449.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] "What is a tuple" design team Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 May 2003 16:06:48 -0400 Content-Transfer-Encoding: 7bit We will be forming a design team that will propose a conclusion to the "what is a tuple" conversation. This team will meet next week and will be operating under an aggressive deadline (3 or fewer weeks). If you wish to participate and can spend significant time on this effort (expect one or more 4 hour meetings per week), send mail to me with your availability next week. I will announce the design team membership next Tuesday. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 16:14:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25975 for ; Fri, 30 May 2003 16:14:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UKDio01873 for simple-archive@odin.ietf.org; Fri, 30 May 2003 16:13:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKDiB01870 for ; Fri, 30 May 2003 16:13:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25943; Fri, 30 May 2003 16:13:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LqEK-0000xW-00; Fri, 30 May 2003 16:12:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LqEK-0000xR-00; Fri, 30 May 2003 16:12:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UK8LB01593; Fri, 30 May 2003 16:08:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UK7OB01249 for ; Fri, 30 May 2003 16:07:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25757 for ; Fri, 30 May 2003 16:07:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lq8E-0000uq-00 for simple@ietf.org; Fri, 30 May 2003 16:05:42 -0400 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19Lq8D-0000ua-00 for simple@ietf.org; Fri, 30 May 2003 16:05:41 -0400 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 h4UK6o610045 for ; Fri, 30 May 2003 15:06:51 -0500 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1054325208.935.449.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] "What is a tuple" design team Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: 30 May 2003 16:06:48 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We will be forming a design team that will propose a conclusion to the "what is a tuple" conversation. This team will meet next week and will be operating under an aggressive deadline (3 or fewer weeks). If you wish to participate and can spend significant time on this effort (expect one or more 4 hour meetings per week), send mail to me with your availability next week. I will announce the design team membership next Tuesday. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri May 30 18:04:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00239; Fri, 30 May 2003 18:04:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lrxa-000256-00; Fri, 30 May 2003 18:02:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LrxZ-000253-00; Fri, 30 May 2003 18:02:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ULxFB10117; Fri, 30 May 2003 17:59:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ULwEB10068 for ; Fri, 30 May 2003 17:58:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29931 for ; Fri, 30 May 2003 17:58:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LrrR-00022l-00 for simple@ietf.org; Fri, 30 May 2003 17:56:29 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19LrrR-00021r-00 for simple@ietf.org; Fri, 30 May 2003 17:56:29 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h4ULvZD12227; Fri, 30 May 2003 17:57:36 -0400 (EDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h4ULroO20837; Fri, 30 May 2003 16:53:50 -0500 (CDT) Message-ID: <3ED7D2E5.1000108@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 Subject: Re: [Simple] "What is a tuple" design team References: <1054325208.935.449.camel@RjS.localdomain> 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, 30 May 2003 16:53:41 -0500 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > We will be forming a design team that will propose a > conclusion to the "what is a tuple" conversation. This > team will meet next week and will be operating under > an aggressive deadline (3 or fewer weeks). Robert: Could you please post a summary/notes of the "what is a tuple" conversation to the WG list? Much as I would have liked to make it to the interim meeting, I could not and would like to see what transpired at that particular session, at the very least. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From mailnull@www1.ietf.org Fri May 30 18:05:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00313 for ; Fri, 30 May 2003 18:05:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UM4aw10318 for simple-archive@odin.ietf.org; Fri, 30 May 2003 18:04:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UM4aB10315 for ; Fri, 30 May 2003 18:04:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00239; Fri, 30 May 2003 18:04:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Lrxa-000256-00; Fri, 30 May 2003 18:02:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LrxZ-000253-00; Fri, 30 May 2003 18:02:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ULxFB10117; Fri, 30 May 2003 17:59:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4ULwEB10068 for ; Fri, 30 May 2003 17:58:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29931 for ; Fri, 30 May 2003 17:58:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LrrR-00022l-00 for simple@ietf.org; Fri, 30 May 2003 17:56:29 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19LrrR-00021r-00 for simple@ietf.org; Fri, 30 May 2003 17:56:29 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h4ULvZD12227; Fri, 30 May 2003 17:57:36 -0400 (EDT) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h4ULroO20837; Fri, 30 May 2003 16:53:50 -0500 (CDT) Message-ID: <3ED7D2E5.1000108@lucent.com> From: "Vijay K. Gurbani" Organization: Wireless Netwoks Group 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 Subject: Re: [Simple] "What is a tuple" design team References: <1054325208.935.449.camel@RjS.localdomain> 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, 30 May 2003 16:53:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > We will be forming a design team that will propose a > conclusion to the "what is a tuple" conversation. This > team will meet next week and will be operating under > an aggressive deadline (3 or fewer weeks). Robert: Could you please post a summary/notes of the "what is a tuple" conversation to the WG list? Much as I would have liked to make it to the interim meeting, I could not and would like to see what transpired at that particular session, at the very least. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sat May 31 00:51:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11633; Sat, 31 May 2003 00:51:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyJH-0004wR-00; Sat, 31 May 2003 00:49:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LyJH-0004wO-00; Sat, 31 May 2003 00:49:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4kIB03691; Sat, 31 May 2003 00:46:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4j4B03645 for ; Sat, 31 May 2003 00:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11557 for ; Sat, 31 May 2003 00:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyDA-0004ua-00 for simple@ietf.org; Sat, 31 May 2003 00:43:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LyD9-0004u8-00 for simple@ietf.org; Sat, 31 May 2003 00:43:19 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V4iWZE005103; Sat, 31 May 2003 00:44:33 -0400 (EDT) Message-ID: <3ED7EA19.3060006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <2038BCC78B1AD641891A0D1AE133DBB7FE7678@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7678@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, 30 May 2003 19:32:41 -0400 Content-Transfer-Encoding: 7bit It becomes really helpful if you ever run into a case where you want to go back and forth between filters within the context of a subscription. -Jonathan R. hisham.khartabil@nokia.com wrote: > Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Thursday, May 29, 2003 8:08 PM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: AndrewAllen007@aol.com; simple@ietf.org >>Subject: placing filters in refreshes, was: Re: [Simple] RE: >>Comments on >>draft-khartabil-simple-filter-funct-00 >> >> >> >> >>hisham.khartabil@nokia.com wrote: >> >>>>As I stated in my earlier email regarding the requirement draft I >>>>have a concern with the replace semantics of the filter criteria >>>>in the Subscribe. I am concerned that the filter criteria could >>>>become quite large especially if the watcher has different filter >>>>criteria for different presentities within presence lists. Do we >>>>need to have every refresh subscriptions include all the filter >>>>criteria for every presentity being watching everytime as our >>>>goal is bandwidth efficiency between the watcher and the network? >>>>I think that filter criteria will be modified by watchers a lot >>>>less regularly than the period of refresh subscriptions and so it >>>>is better to have some very small extra overhead when creating, >>>>modifying or deleting the filter than having to include the >>>>filter criteria in every refresh. I think some similar >>>>functionality to the partial drafts may be the way forward here. >>> >>> >>>As I commented earlier, I share your concern and will look into it >>>before the next version of the I-D is released. >> >>I have an idea here. >> >>THe idea is that, instead of sending the filter, the >>SUBSCRIBE refresh >>includes a hash of the filter as the body of the request (with a >>content-type along the lines of filter-hash or something). The server >>checks the hash to see if it maps against any existing filter >>that has >>been used in this dialog (and indeed, part of different dialogs too - >>would allow for sharing of filters). If so, the server acts >>as if that >>filter was in the body of the SUBSCRIBE. If not, it rejects teh >>request and the client can re-try with the full filter. >> >>Basically, this is caching of filter documents, using a hash of the >>document as a reference to a cache entry. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Scientist 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 Scientist 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 mailnull@www1.ietf.org Sat May 31 00:51:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11653 for ; Sat, 31 May 2003 00:51:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V4pOh03869 for simple-archive@odin.ietf.org; Sat, 31 May 2003 00:51:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4pOB03866 for ; Sat, 31 May 2003 00:51:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11633; Sat, 31 May 2003 00:51:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyJH-0004wR-00; Sat, 31 May 2003 00:49:39 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LyJH-0004wO-00; Sat, 31 May 2003 00:49:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4kIB03691; Sat, 31 May 2003 00:46:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4j4B03645 for ; Sat, 31 May 2003 00:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11557 for ; Sat, 31 May 2003 00:44:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyDA-0004ua-00 for simple@ietf.org; Sat, 31 May 2003 00:43:20 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LyD9-0004u8-00 for simple@ietf.org; Sat, 31 May 2003 00:43:19 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V4iWZE005103; Sat, 31 May 2003 00:44:33 -0400 (EDT) Message-ID: <3ED7EA19.3060006@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org Subject: Re: placing filters in refreshes, was: Re: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 References: <2038BCC78B1AD641891A0D1AE133DBB7FE7678@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7678@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, 30 May 2003 19:32:41 -0400 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It becomes really helpful if you ever run into a case where you want to go back and forth between filters within the context of a subscription. -Jonathan R. hisham.khartabil@nokia.com wrote: > Sounds like a reasonable idea. But the question is if its more complicated that adding an element or attribute that indicates removal of a filter using the filter id. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >>Sent: Thursday, May 29, 2003 8:08 PM >>To: Khartabil Hisham (NMP/Helsinki) >>Cc: AndrewAllen007@aol.com; simple@ietf.org >>Subject: placing filters in refreshes, was: Re: [Simple] RE: >>Comments on >>draft-khartabil-simple-filter-funct-00 >> >> >> >> >>hisham.khartabil@nokia.com wrote: >> >>>>As I stated in my earlier email regarding the requirement draft I >>>>have a concern with the replace semantics of the filter criteria >>>>in the Subscribe. I am concerned that the filter criteria could >>>>become quite large especially if the watcher has different filter >>>>criteria for different presentities within presence lists. Do we >>>>need to have every refresh subscriptions include all the filter >>>>criteria for every presentity being watching everytime as our >>>>goal is bandwidth efficiency between the watcher and the network? >>>>I think that filter criteria will be modified by watchers a lot >>>>less regularly than the period of refresh subscriptions and so it >>>>is better to have some very small extra overhead when creating, >>>>modifying or deleting the filter than having to include the >>>>filter criteria in every refresh. I think some similar >>>>functionality to the partial drafts may be the way forward here. >>> >>> >>>As I commented earlier, I share your concern and will look into it >>>before the next version of the I-D is released. >> >>I have an idea here. >> >>THe idea is that, instead of sending the filter, the >>SUBSCRIBE refresh >>includes a hash of the filter as the body of the request (with a >>content-type along the lines of filter-hash or something). The server >>checks the hash to see if it maps against any existing filter >>that has >>been used in this dialog (and indeed, part of different dialogs too - >>would allow for sharing of filters). If so, the server acts >>as if that >>filter was in the body of the SUBSCRIBE. If not, it rejects teh >>request and the client can re-try with the full filter. >> >>Basically, this is caching of filter documents, using a hash of the >>document as a reference to a cache entry. >> >>-Jonathan R. >> >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Scientist 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 Scientist 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 May 31 00:53: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 AAA11690; Sat, 31 May 2003 00:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyKz-0004ws-00; Sat, 31 May 2003 00:51:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LyKy-0004wp-00; Sat, 31 May 2003 00:51:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4m5B03758; Sat, 31 May 2003 00:48:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4j5B03649 for ; Sat, 31 May 2003 00:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11560 for ; Sat, 31 May 2003 00:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyDA-0004uf-00 for simple@ietf.org; Sat, 31 May 2003 00:43:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LyDA-0004u9-00 for simple@ietf.org; Sat, 31 May 2003 00:43:20 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V4iYZE005106; Sat, 31 May 2003 00:44:34 -0400 (EDT) Message-ID: <3ED7EAAA.403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB7FE7674@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7674@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h4V4iYZE005106 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4V4j5B03650 Subject: [Simple] Re: Use of 202 response for subscription with filter (was :RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-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: Fri, 30 May 2003 19:35:06 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4V4m5B03758 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA11690 Well, I'm not Adam but I'll comment. I think that the operation should be atomic; if you accept the subscription, you also accept the filter. I think it is worth making this clear in the filtering mechanism spec, since it will undoubtedly cause confusion otherwise. -Jonathan R. hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] >>Sent: Thursday, May 29, 2003 6:32 PM >>To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org >>Cc: AndrewAllen007@aol.com >>Subject: Re: [Simple] RE: Comments on >>draft-khartabil-simple-filter-funct-00 >> >> >>>Next comment relates to clause 3.3.4 Subscriber Interpreting >>>SIP responses, clause 5.2 Notifier Processing SUBSCRIBE >>>Requests, and clause 5.4 Handling Abnormal Cases: >>> >>>The meaning of 200 and 202 responses to Subscribe requests is >>>already defined in RFC 3265 and they relate to the state of >>>the subscription I don’t think we should further extend their >>>meaning to also include a meaning to the state of the filter >>>criteria. It seems the server has four basic options: >>> >>>1) It can accept the subscription and also accept the filter >>>criteria. – 200 OK >>>2) It can accept the subscription but ignore all the filter >>>criteria - 200 OK >>>3) It can reject the subscription (which also rejects the >>>filter criteria) - 4xxx >>>4) It can indicate that the subscription has been >>>understood, and that authorization may or may not have been >>>granted. - 202 >> >>I think the text as it is now is ok. Some implementations of >>the server might want to examine the filter after responding >>to the SUBSCRIBE. A 202 in this case is needed. >> >>[AA] My concern is with extending the meaning of 200 OK and >>202 from that stated in RFC 3265. The text of concern is in >>clause 5.2 “A "200" response indicates that the subscription >>has been accepted, the user is authorized and the filter is >>accepted.” AND “A "202" response also indicates that the >>filter criteria have not been accepted yet.” >> >>[AA] IMO even if we go with the approach of rejecting the >>subscription if the filter criteria is rejected we do not >>need this text since the RFC 3265 wording still applies – the >>subscription is either rejected or authorised or pending. If >>the implementation wants to examine the filter criteria >>before authorising the subscription then a 202 is appropriate >>and I think this is covered in 3265 as well. If we choose to >>always reject the subscription if the filter criteria is not >>acceptable then all we need to state in the draft is that >>rejection of the filter criteria means that the subscription >>must also be rejected as you propose below. >> > > > I still think we need to spell it out in the filtering draft. What do you think Adam? > > > /Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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 mailnull@www1.ietf.org Sat May 31 00:53:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11705 for ; Sat, 31 May 2003 00:53:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V4rAR03955 for simple-archive@odin.ietf.org; Sat, 31 May 2003 00:53:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4rAB03952 for ; Sat, 31 May 2003 00:53:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11690; Sat, 31 May 2003 00:53:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyKz-0004ws-00; Sat, 31 May 2003 00:51:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19LyKy-0004wp-00; Sat, 31 May 2003 00:51:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4m5B03758; Sat, 31 May 2003 00:48:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V4j5B03649 for ; Sat, 31 May 2003 00:45:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11560 for ; Sat, 31 May 2003 00:45:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyDA-0004uf-00 for simple@ietf.org; Sat, 31 May 2003 00:43:21 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19LyDA-0004u9-00 for simple@ietf.org; Sat, 31 May 2003 00:43:20 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h4V4iYZE005106; Sat, 31 May 2003 00:44:34 -0400 (EDT) Message-ID: <3ED7EAAA.403@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: AndrewAllen007@aol.com, simple@ietf.org References: <2038BCC78B1AD641891A0D1AE133DBB7FE7674@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7FE7674@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id h4V4iYZE005106 X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4V4j5B03650 Subject: [Simple] Re: Use of 202 response for subscription with filter (was :RE: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-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: Fri, 30 May 2003 19:35:06 -0400 X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h4V4m5B03758 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4V4rAB03952 Content-Transfer-Encoding: 8bit Well, I'm not Adam but I'll comment. I think that the operation should be atomic; if you accept the subscription, you also accept the filter. I think it is worth making this clear in the filtering mechanism spec, since it will undoubtedly cause confusion otherwise. -Jonathan R. hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext AndrewAllen007@aol.com [mailto:AndrewAllen007@aol.com] >>Sent: Thursday, May 29, 2003 6:32 PM >>To: Khartabil Hisham (NMP/Helsinki); simple@ietf.org >>Cc: AndrewAllen007@aol.com >>Subject: Re: [Simple] RE: Comments on >>draft-khartabil-simple-filter-funct-00 >> >> >>>Next comment relates to clause 3.3.4 Subscriber Interpreting >>>SIP responses, clause 5.2 Notifier Processing SUBSCRIBE >>>Requests, and clause 5.4 Handling Abnormal Cases: >>> >>>The meaning of 200 and 202 responses to Subscribe requests is >>>already defined in RFC 3265 and they relate to the state of >>>the subscription I don’t think we should further extend their >>>meaning to also include a meaning to the state of the filter >>>criteria. It seems the server has four basic options: >>> >>>1) It can accept the subscription and also accept the filter >>>criteria. – 200 OK >>>2) It can accept the subscription but ignore all the filter >>>criteria - 200 OK >>>3) It can reject the subscription (which also rejects the >>>filter criteria) - 4xxx >>>4) It can indicate that the subscription has been >>>understood, and that authorization may or may not have been >>>granted. - 202 >> >>I think the text as it is now is ok. Some implementations of >>the server might want to examine the filter after responding >>to the SUBSCRIBE. A 202 in this case is needed. >> >>[AA] My concern is with extending the meaning of 200 OK and >>202 from that stated in RFC 3265. The text of concern is in >>clause 5.2 “A "200" response indicates that the subscription >>has been accepted, the user is authorized and the filter is >>accepted.” AND “A "202" response also indicates that the >>filter criteria have not been accepted yet.” >> >>[AA] IMO even if we go with the approach of rejecting the >>subscription if the filter criteria is rejected we do not >>need this text since the RFC 3265 wording still applies – the >>subscription is either rejected or authorised or pending. If >>the implementation wants to examine the filter criteria >>before authorising the subscription then a 202 is appropriate >>and I think this is covered in 3265 as well. If we choose to >>always reject the subscription if the filter criteria is not >>acceptable then all we need to state in the draft is that >>rejection of the filter criteria means that the subscription >>must also be rejected as you propose below. >> > > > I still think we need to spell it out in the filtering draft. What do you think Adam? > > > /Hisham > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist 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