From simple-admin@mailman.dynamicsoft.com Thu Oct 18 09:58:52 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10420 for ; Thu, 18 Oct 2001 09:58:52 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9IDu78P025288; Thu, 18 Oct 2001 09:56:07 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14159; Thu, 18 Oct 2001 09:56:32 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14146 for ; Thu, 18 Oct 2001 09:55:44 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9IDsM8P025265 for ; Thu, 18 Oct 2001 09:54:22 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQNV6>; Thu, 18 Oct 2001 09:55:32 -0400 Message-ID: From: Jonathan Rosenberg To: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] test - please ignore Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 18 Oct 2001 09:55:31 -0400 --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Oct 19 18:05:25 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02769 for ; Fri, 19 Oct 2001 18:05:25 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9JM2q8P007372; Fri, 19 Oct 2001 18:02:53 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19878; Fri, 19 Oct 2001 18:03:20 -0400 (EDT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA19867 for ; Fri, 19 Oct 2001 18:02:24 -0400 (EDT) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw5.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id f9JM27e06882 for ; Fri, 19 Oct 2001 17:02:07 -0500 (CDT) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89) id <4YT3KDKJ>; Fri, 19 Oct 2001 17:02:07 -0500 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7B66@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Question on status of the work Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Fri, 19 Oct 2001 17:02:04 -0500 I have just joined the group and I've been trying to determine the status of your I-D's. We are interested in the possible use of SIP for instant messaging and need feedback on what the timeframe for RFC status of this work may be. Any feedback is appreciated. Thanks, Mark A. Lipford Sprint PCS Manager, Wireless Industry Standards - Data Technology 15405 College Blvd. Mailstop: KSLNXZ0201-2148 Lenexa, KS 66219 (913) 890+4248 (office) (913) 890-4291 (fax) (913) 226-9060 (PCS) _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:02:21 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29785 for ; Wed, 24 Oct 2001 10:02:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9ODx2PI017251; Wed, 24 Oct 2001 09:59:02 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00264; Wed, 24 Oct 2001 09:59:33 -0400 (EDT) Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92] (may be forged)) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id JAA00250 for ; Wed, 24 Oct 2001 09:58:20 -0400 (EDT) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [63.113.40.50]) with SMTP; 24 Oct 2001 13:58:06 UT Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 24 Oct 2001 11:54:16 +0100 From: "Neil Deason" To: "Jonathan Rosenberg" , "Brian Stucker" , "Brazier Lachlan" , "''SIMPLE Mailinglist' '" Subject: RE: [Simple] Multiple 200 Ok Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: X-OriginalArrivalTime: 24 Oct 2001 10:54:16.0144 (UTC) FILETIME=[395FF500:01C15C7A] Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 11:54:15 +0100 Content-Transfer-Encoding: 7bit I would agree with this. The usage of a 403 needs to be clear that it doesn't mean the SUBSCRIBE should never be repeated as that may not be obvious from the HTTP inherited meaning. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 24 October 2001 01:45 > To: Brian Stucker; Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; > ''SIMPLE Mailinglist' ' > Subject: RE: [Simple] Multiple 200 Ok > > > Another old issue that I want to make sure is closed. > > Let me summarize the discussion. The question was this: if a PA gets a > request, and the request-uri matches that of a user that the > PA represents, > but the To field doesn't, what do you do? The conclusion of > this thread is > that it is up to the policy of the PA as to whether it > accepts subscriptions > that were originally targeted at a different UA (which is > what it means when > the r-uri and to field don't identify the same user). This is > not presence > specific at all, as this happens with sip in general when requests are > forwarded. The only question was this: what response code to > use in this > case? > > I believe 403 is correct; it does not imply that the > subscription can never > be retried, just that right now, retrying it against this PA > won't help any > more. > > Furthermore, this is not presence specific, and belongs in SIP itself. > bis-05 actually has a subsection on UAS processing which > describes how a uas > determines if it should process a request. The section > provides response > codes to use in specific cases, and this case, and the 403, will be > described there. I will also mention this case in the presence spec. > > -Jonathan R. > > > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > -----Original Message----- > From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > Sent: Friday, October 05, 2001 11:10 AM > To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE > Mailinglist' ' > Subject: RE: [Simple] Multiple 200 Ok > > > Would it be a 403 forbidden? If a 403 were sent back because the > only routable PA wasn't willing to process the subscription, wouldn't > this cause the would-be watcher to not try again later when other > PA's may be available (via forking) that could process the request? > I would think a 404 or a 488 response would be a better fit. > ... > When is that new events draft going to appear? Until that comes out > the NOTIFY with expires = 0 is the way you force-expire a > subscription. > Regards, > Brian > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Friday, October 05, 2001 9:52 AM > To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian > [NGB:B621:EXCH]; ''SIMPLE Mailinglist' ' > Subject: RE: [Simple] Multiple 200 Ok > > > > -----Original Message----- > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > > > Hi, > > > > generally I agree with you about Authorisation and Authentication. > > > > Let me reformulate the question. Which response do I send > back, when I > > received a SUBSCRIBE, and I'm not allowed or not willing to be the > > presentity (This can happen if someone defines me as > > presentity without > > letting me know - as the way of authorization is not in the > > scope of the > > presence draft, errors might happen)? > 403 would do. > > I have a question concerning the Call flows in the draft. > > When a PA receives a SUBSCRIBE with an Expires header, the > > response contains > > an Expires header as well. What would an Expires header in a > > NOTIFY request > > sent from the PA to the Watcher mean? Would this update the > > subscription > > expiration time? > > > > An example: > > userA subscribes for user userB. As userB is a friend of > > userA, he accepts > > the subscription and the call flows just get on. > > After some time userB doesn't want to be the presentity of > > userA anymore, or > > maybe userB changes the contact information for the SUBSCRIBE > > request at > > it's registrar. > > Now, can userB (better said the PA of userB) send a NOTIFY > > with an Expires > > header with value 0 to tell userA, that it's subscription > > expiration time is > > over? > > > > I think it should be possible to do so, because if not, userB > > would need to > > wait for the next SUBSCRIBE request from userA, before he can > > tell him, that > > the subscription time is over. This could be a time value > > from seconds to > > days, month, years, etc. > > > > > > If there is another mechanism to do so, which one would it > be? Maybe a > > NOTIFY with an empty body? > There current proposal is to use a new header, > Subscription-Expires in NOTIFY instead of overloading > Expires to indicate when a subscription will end. > draft-ietf-simple-presence-03.txt refers to this in > describing how PA functionality migrates (5.12). This > header still needs to be detailed in a revised 'SIP > specific event notification' draft. > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:14:22 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00394 for ; Wed, 24 Oct 2001 10:14:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OEBgPI017395; Wed, 24 Oct 2001 10:11:42 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00390; Wed, 24 Oct 2001 10:13:09 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00297 for ; Wed, 24 Oct 2001 10:07:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iQPI014277; Tue, 23 Oct 2001 20:44:29 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 20:45:38 -0400 Message-ID: From: Jonathan Rosenberg To: sal , simple@mailman.dynamicsoft.com Subject: RE: [Simple] notify after terminating subscription MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Oct 2001 20:45:29 -0400 The reason that a NOTIFY is still sent is that we want the behavior of SUBSCRIBE to be consistent; a 200 OK response to SUBSCRIBE always generates a NOTIFY, independent of the duration of the subscription. This allows a single primitive to be used for fetch, terminating a subscription, creating one, and refreshing one. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: sal [mailto:salvatore.loreto@libero.it] > Sent: Tuesday, October 09, 2001 4:55 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] notify after terminating subscription > > > Hi, > > i'm looking, on the presence's draft, > the flow messages "Client to Client Subscription > with Presentity State Change" > > why when the watcher terminating the subscription > it receive after a 200OK also an other NOTIFY from > that presentity? > i don't understood ... > > thanks > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:14:42 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00413 for ; Wed, 24 Oct 2001 10:14:42 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OEC0PI017419; Wed, 24 Oct 2001 10:12:00 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00406; Wed, 24 Oct 2001 10:13:28 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00303 for ; Wed, 24 Oct 2001 10:07:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iQPI014276; Tue, 23 Oct 2001 20:44:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 20:45:38 -0400 Message-ID: From: Jonathan Rosenberg To: Brian Stucker , Jonathan Rosenberg , Brazier Lachlan , Jonathan Rosenberg , "''Neil Deason' '" , "''SIMPLE Mailinglist' '" Subject: RE: [Simple] Multiple 200 Ok MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Oct 2001 20:45:29 -0400 Another old thread. The issue was how a subscriber knows the identity of the actual PA which answered the SUBSCRIBE, since it may have been forwarded. Response inline. -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, October 05, 2001 11:02 AM To: Jonathan Rosenberg; Brazier Lachlan; Jonathan Rosenberg; ''Neil Deason' '; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok >I'm a bit worried about using the contact header in the 2xx as a means of >identifying the user that processed the SUBSCRIBE. The watcher has no method >of determining the user's contact list to check the contact received >against. So I don't see a reliable method of taking a contact and determining >the user that contact is for unless you're the registrar (and even then it >can be ambiguous). If you have a proxy that straddles a firewall, it will >probably modify the contact address in the 2xx response, so the contact returned >may be one that only the proxy knows who it maps to, and nobody else. I agree that Contact is far from ideal. Remote-Party-ID is really much better, since it provides a logical identity, and thats exactly what you want. I don't want to mandate the usage of R-PID for this, as it introduces a dependency. So, I will simply indicate that the privacy spec can be used if you want to provide the identity of the PA which actually answered. This makes the reference non-normative and therefore there is no dependency. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:14:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00426 for ; Wed, 24 Oct 2001 10:14:48 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OECCPI017456; Wed, 24 Oct 2001 10:12:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00422; Wed, 24 Oct 2001 10:13:40 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00299 for ; Wed, 24 Oct 2001 10:07:35 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iFPI014256; Tue, 23 Oct 2001 20:44:16 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 20:45:28 -0400 Message-ID: From: Jonathan Rosenberg To: "Moran Tim (NET/Dallas)" , "'ext Paul Kyzivat'" , Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Oct 2001 20:45:27 -0400 -----Original Message----- From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com] Sent: Friday, October 05, 2001 11:33 AM To: 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] 200 vs. 202 > >While 5.7 paragraph 6 indicates that the Notifier can send whatever, the first paragraph >of 5.10 states "Each of these [PA] will respond with a 202 response to the SUBSCRIBE." >The later does not imply whatever can be sent.. You are looking at an older version of the specification. This was true in -02. -03 has a 2xx where 202 appears, and has thus fixed this problem you have found. > >Given your comments are correct, then I would suggest changing the 1st paragraph of 5.10 >so as not to restrict what can be sent by the PA (After all - can the Notifier (PA) even >tell it is a 5.7 subscribe vs. a 5.10 (forked) subscribe?). On a side note, the doc uses >Notifier for section titles wherein the text uses e.g. PA. Is this semantically correct? >Are we really intending to talk about PA Notifiers vs. other type of Notifiers? Don't >mean to be picky but I'm not sure if this is intentional, and thus adds explicit meaning, >or just loose use of terminology. The section titles follow the section titles in sip-events. A Notifier = PA; that is, a PA is a notifier for the presence package. I will state this in the terminology section. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:14:57 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00438 for ; Wed, 24 Oct 2001 10:14:56 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OECOPI017512; Wed, 24 Oct 2001 10:12:24 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00438; Wed, 24 Oct 2001 10:13:51 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00307 for ; Wed, 24 Oct 2001 10:07:36 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9O0iQPI014278; Tue, 23 Oct 2001 20:44:26 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Oct 2001 20:45:38 -0400 Message-ID: From: Jonathan Rosenberg To: Brian Stucker , Neil Deason , Brazier Lachlan , "'Jonathan Rosenberg'" , "''SIMPLE Mailinglist' '" Subject: RE: [Simple] Multiple 200 Ok MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Tue, 23 Oct 2001 20:45:28 -0400 Another old issue that I want to make sure is closed. Let me summarize the discussion. The question was this: if a PA gets a request, and the request-uri matches that of a user that the PA represents, but the To field doesn't, what do you do? The conclusion of this thread is that it is up to the policy of the PA as to whether it accepts subscriptions that were originally targeted at a different UA (which is what it means when the r-uri and to field don't identify the same user). This is not presence specific at all, as this happens with sip in general when requests are forwarded. The only question was this: what response code to use in this case? I believe 403 is correct; it does not imply that the subscription can never be retried, just that right now, retrying it against this PA won't help any more. Furthermore, this is not presence specific, and belongs in SIP itself. bis-05 actually has a subsection on UAS processing which describes how a uas determines if it should process a request. The section provides response codes to use in specific cases, and this case, and the 403, will be described there. I will also mention this case in the presence spec. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, October 05, 2001 11:10 AM To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok Would it be a 403 forbidden? If a 403 were sent back because the only routable PA wasn't willing to process the subscription, wouldn't this cause the would-be watcher to not try again later when other PA's may be available (via forking) that could process the request? I would think a 404 or a 488 response would be a better fit. ... When is that new events draft going to appear? Until that comes out the NOTIFY with expires = 0 is the way you force-expire a subscription. Regards, Brian -----Original Message----- From: Neil Deason [mailto:ndeason@ubiquity.net] Sent: Friday, October 05, 2001 9:52 AM To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian [NGB:B621:EXCH]; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Hi, > > generally I agree with you about Authorisation and Authentication. > > Let me reformulate the question. Which response do I send back, when I > received a SUBSCRIBE, and I'm not allowed or not willing to be the > presentity (This can happen if someone defines me as > presentity without > letting me know - as the way of authorization is not in the > scope of the > presence draft, errors might happen)? 403 would do. > I have a question concerning the Call flows in the draft. > When a PA receives a SUBSCRIBE with an Expires header, the > response contains > an Expires header as well. What would an Expires header in a > NOTIFY request > sent from the PA to the Watcher mean? Would this update the > subscription > expiration time? > > An example: > userA subscribes for user userB. As userB is a friend of > userA, he accepts > the subscription and the call flows just get on. > After some time userB doesn't want to be the presentity of > userA anymore, or > maybe userB changes the contact information for the SUBSCRIBE > request at > it's registrar. > Now, can userB (better said the PA of userB) send a NOTIFY > with an Expires > header with value 0 to tell userA, that it's subscription > expiration time is > over? > > I think it should be possible to do so, because if not, userB > would need to > wait for the next SUBSCRIBE request from userA, before he can > tell him, that > the subscription time is over. This could be a time value > from seconds to > days, month, years, etc. > > > If there is another mechanism to do so, which one would it be? Maybe a > NOTIFY with an empty body? There current proposal is to use a new header, Subscription-Expires in NOTIFY instead of overloading Expires to indicate when a subscription will end. draft-ietf-simple-presence-03.txt refers to this in describing how PA functionality migrates (5.12). This header still needs to be detailed in a revised 'SIP specific event notification' draft. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:15:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00456 for ; Wed, 24 Oct 2001 10:15:16 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OECnPI017613; Wed, 24 Oct 2001 10:12:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00476; Wed, 24 Oct 2001 10:14:16 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00324 for ; Wed, 24 Oct 2001 10:07:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CePI007252; Mon, 22 Oct 2001 21:12:53 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQYT8>; Mon, 22 Oct 2001 21:13:52 -0400 Message-ID: From: Jonathan Rosenberg To: Brazier Lachlan , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Contact header in MESSAGE request MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Oct 2001 21:13:50 -0400 > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Tuesday, October 16, 2001 3:48 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Contact header in MESSAGE request > > > Hello, > > I've been reading draft-ietf-simple-im-01, and at the end I > read Appendix A. > Requirements Evaluation. > > "Requirement 4.1.3. The common message format MUST include a return > address for the receiver to reply to the sender with another > INSTANT MESSAGE." This is done through the Contact headers > defined in SIP. > > Does this mean that the Contact header is mandatory in an > MESSAGE request? > It's not according to the table of header fields. This is something that has changed a bit as the session model has evolved into a separate entity. The initial model was that MESSAGE itself set up a session, but this was discarded as we didn't want multiple ways to establish an interaction communicastions session, and certainly voice/video could be part of that. In this initial model, since MESSAGE was like INVITE, it had a Contact header that was used for sending subsequent messages within the session. Then, with the paging model, MESSAGE became a "one-shot" kind of thing. There is no session or context for the messages. Since Contact is meant to provide an endpoint address, its not very useful for paging mode. In these cases, you can't really provide a a host address, since these things change, and the duration during which that address would remain useful is unknown. Providing a direct host address is only useful where there is a session, and we can change it if the host moves (SIP provides this ability). So, Contact doesn't make sense anymore. Thats why its not in the table. However, one might want to provide a reply address that isn't a host IP or hostname. Rather, we want to provide a logical address to send messages in reply. Normally, the From is used for this kind of thing, but certainly the address for sending a response could be something else. Right now, there is no Reply-To header in SIP. It would be a useful thing to have, as it makes sense for initiating calls as well (If I call you, and you're not there, I can provide a logical address to use to call me back at any point later on). In fact, this is a current open issue in the bis specification itself (whether or not to add a Reply-To address). Oddly, bis does have an In-Reply-To header that identifies the specific call that a new call is in reply to. Since we have multiple cases where it is needed, sounds like its something that should be added. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:15:44 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00496 for ; Wed, 24 Oct 2001 10:15:43 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OECZPI017558; Wed, 24 Oct 2001 10:12:35 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00456; Wed, 24 Oct 2001 10:14:03 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00320 for ; Wed, 24 Oct 2001 10:07:40 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CgPI007264; Mon, 22 Oct 2001 21:12:42 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQY4A>; Mon, 22 Oct 2001 21:13:54 -0400 Message-ID: From: Jonathan Rosenberg To: "Petri K. Koskelainen" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] IM format MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Oct 2001 21:13:52 -0400 > -----Original Message----- > From: Petri K. Koskelainen [mailto:petkos@cs.columbia.edu] > Sent: Friday, October 12, 2001 1:51 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] IM format > > > Hi, > > Message and thread identification is essential for > session based IM format as described in > "Group Messaging in SIP" draft. > > Thread identification is not very useful in two-party chat, > but in multi-party chat (and some non-chat applicatios) > it is a necessity. > > Thread-id header itself is not needed. > Instead, thread identification can be achieved > with Message-id and References headers. > It allows also nested threads. Sounds like good reasons not to try and do multiparty chat with the paging model. We have spent much time on getting multiparty communications working with SIP. Using session model allows all of that to be reused. If you want to support multiparty chats in page model, you will be reinventing a completely new and orthogonal mechanisms for much the same thing. I think that this is a bad thing. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:15:47 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00506 for ; Wed, 24 Oct 2001 10:15:47 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OEDCPI017721; Wed, 24 Oct 2001 10:13:12 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00498; Wed, 24 Oct 2001 10:14:34 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00330 for ; Wed, 24 Oct 2001 10:07:41 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CePI007253; Mon, 22 Oct 2001 21:12:40 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQYT7>; Mon, 22 Oct 2001 21:13:52 -0400 Message-ID: From: Jonathan Rosenberg To: Brian Stucker , Jonathan Rosenberg , "'Lessing, Francois'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Oct 2001 21:13:51 -0400 I'm not sure I know what you mean by this. If you want to subscribe to some state associated with a call leg, then the subscribe has to identify that call leg. This identification should be explicit (i.e., carried somewhere in the subscription), rather than implicit based on the fact that it arrived on a particular call leg. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Monday, October 15, 2001 6:46 PM To: Jonathan Rosenberg; 'Lessing, Francois'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY What about tag matching from forking interactions? I figured that the requirement to keep in the same call leg was simply put there to help out with tag matching. Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Saturday, October 13, 2001 9:29 AM To: 'Lessing, Francois'; simple@mailman.dynamicsoft.com Subject: RE: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY We have debated this before, with the general conclusion that a SUBSCRIBE within a call leg should behave no differently than one outside of the leg. The fact that its already within a leg simply means that the route sets and CSeq are established, rather than needing to have been established by an initial INVITE. The fact that its in a call leg would change nothing about identifying whats being subscribed to. I see no particular benefit to placing a subscription within a call leg (although I do see benefit in using the route headers from an existing call leg), but I see no strong reason to forbid it. -Jonathan R. > -----Original Message----- > From: Lessing, Francois [mailto:francoisx.lessing@intel.com] > Sent: Monday, October 08, 2001 8:35 PM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] Re-use of Call leg information in SUBCRIBE-NOTIFY > > > Hi everyone, > > The event notification drafts 'discourages' re-use of > call leg information [1] (see quote from draft at end of mail) > > Does this mean we sometimes allow a SUBSCRIBE > request on an existing call leg created by INVITE ? > > To me this would not make sense, it seems to > go against the broader intention of the draft. > > The only reason I can think where this might be > useful, is to SUBSCRIBE to a resource that is > associated with an existing call leg. > > But, an event is only allowed to be identified > by event type, Request URI, and message body > as per the event notification draft [2] > > If this behaviour is allowed, it also opens the door > for other questions that have not been addressed: > > Q.How would a subscription terminate ? > A.When its associated call leg dies due to BYE ? > A. Wen it receives a SUBSCRIBE with expires = 0 ? > etc. > > Is there a reason that we cannot replace the 'discouraged' > at the end of [1] with a "NOT ALLOWED" ? > > Any thoughts would be apreciated, > > Francois Lessing > Trillium Digital Systems, an Intel company. > > > References: > > [1] SIP-Specific Event Notification, Section 5.1.1: > "The relationship between subscriptions and (INVITE-initiated) > sessions sharing the same call leg identification information is > undefined. Re-using call leg information for subscriptions is > discouraged." > > > [2] SIP-Specific Event Notification, Section 5.1.1: > Identification of events is provided by three pieces of > information: Request URI, Event Type, and (optionally) > message body. > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:16:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00530 for ; Wed, 24 Oct 2001 10:16:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OEDnPI017875; Wed, 24 Oct 2001 10:13:49 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00556; Wed, 24 Oct 2001 10:15:11 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00339; Wed, 24 Oct 2001 10:07:42 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N1CiPI007267; Mon, 22 Oct 2001 21:12:44 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQY4B>; Mon, 22 Oct 2001 21:13:56 -0400 Message-ID: From: Jonathan Rosenberg To: Paul Kyzivat , Gur_Kimchi@vocaltec.com Cc: Jonathan Rosenberg , Avshalom@ubique.com, Ben Campbell , "'Rosen, Brian'" , Henning Schulzrinne , "'Christian Huitema'" , "Peterson, Jon" , "Roy, Radhika R, ALCTA" , simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com, Vasilis Polychronidis Subject: RE: [Simple] IM over the signaling connection MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Oct 2001 21:13:55 -0400 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, October 11, 2001 7:29 PM > To: Gur_Kimchi@vocaltec.com > Cc: Jonathan Rosenberg; Avshalom@ubique.com; Ben Campbell; 'Rosen, > Brian'; Henning Schulzrinne; 'Christian Huitema'; Peterson, Jon; Roy, > Radhika R, ALCTA; simple@mailman.dynamicsoft.com; > simple-admin@mailman.dynamicsoft.com; Vasilis Polychronidis > Subject: Re: [Simple] IM over the signaling connection > > > In addition to and , it would be > useful to have > an header, so that proper message ordering can be > achieved. In theory the is sufficient to define > a thread, > but in practice it probably isn't, so having both is useful. SIP actually has an In-Reply-To, which lists the call-id of the message that this request is "replying" to. Effectively, this means that the call-id acts as our message ID in the paging model. Based on the sip definition, call-id is globally unqiue for each request outside of a call-leg. Since paging mode doesn't set up a leg, this has the desired property. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:16:53 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00572 for ; Wed, 24 Oct 2001 10:16:53 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OEDVPI017809; Wed, 24 Oct 2001 10:13:31 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00536; Wed, 24 Oct 2001 10:14:58 -0400 (EDT) Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [192.168.4.30]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00315; Wed, 24 Oct 2001 10:07:37 -0400 (EDT) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9N2m3PI007488; Mon, 22 Oct 2001 22:48:03 -0400 (EDT) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id <495WQYX2>; Mon, 22 Oct 2001 22:49:16 -0400 Message-ID: From: Jonathan Rosenberg To: "'gur@vocaltec.com'" , Paul Kyzivat Cc: Avshalom@ubique.com, Ben Campbell , "'Rosen, Brian'" , Henning Schulzrinne , "'Christian Huitema'" , Jonathan Rosenberg , "Peterson, Jon" , "Roy, Radhika R, ALCTA" , simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com, Vasilis Polychronidis Subject: RE: [Simple] IM over the signaling connection MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Mon, 22 Oct 2001 22:49:15 -0400 One thing I do want to note.... I think that whatever we do for thread IDs, in-reply-to's or whatever should not hold up the basic paging model. All of those things are primarily needed to facilitate integration with a session model, and therefore we should worry about those things later. Lets get the basic paging model done. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: gur@vocaltec.com [mailto:gur@vocaltec.com] > Sent: Thursday, October 11, 2001 8:53 PM > To: Paul Kyzivat > Cc: Avshalom@ubique.com; Ben Campbell; 'Rosen, Brian'; Henning > Schulzrinne; 'Christian Huitema'; Jonathan Rosenberg; Peterson, Jon; > Roy, Radhika R, ALCTA; simple@mailman.dynamicsoft.com; > simple-admin@mailman.dynamicsoft.com; Vasilis Polychronidis > Subject: Re: [Simple] IM over the signaling connection > > > Paul - > > not having the Session-ID and only relaying on the has > some increased statfullness requirements on proxies - and again, my > original > point that while we --hope-- many IM sessions will be end2end, in > reality many inter-domain IM sessions will traverse some DMZ > IM or SIP proxy that will provide authentication and authorization - > domain policy ("this user is blacklisted", "translate between > English and > French") > should be done when entering the network, not by the UA. > > And of course if the proxy is no longer needed it can replace > the u2p2u > session > with an u2u one - another advantage of using standard SIP setup for IM > sessions. > > Also - I believe messages, regardless if sent using pages or > in sessions, > should be associated with a "thread-of-messages ID" - this > makes for a much > cleaner design - not needed in every case mind you, but in many > person2person > scenarios. Also this provides a stateless way for both UAs > and Proxies > to continue past sessions - just choosing some arbitrary time > for a session > to expire -because the transport closed- or -some timer fired- is less > then optimal. I may, as a user, as I do many times, continue a > conversation > I finished last night - and it should contextually be the > same "thread" - > while clearly the transport will be replaced and a new > session created. > > so while I am not objecting to an additional optional > header, > I dont think it replaced . > > - gur > > > Paul Kyzivat Wrote: > > > > In addition to and , it would be > useful to have > > an header, so that proper message ordering can be > > achieved. In theory the is sufficient to > define a thread, > > but in practice it probably isn't, so having both is useful. > > > > On the other hand, having might encourage abuse > of paging > > mode by providing another way to implement sessions. Just having > > and would be sufficient to tie a > new session > > to a preceding page mode message. > > > > > >> Gur_Kimchi@vocaltec.com wrote: > >> > >> Providing messages with two optional headers: and > > >> allows the sender to choose to > >> > >> (1) provide message identification for later processing > (if this is not > >> clear then imagine some message indexing at the server to > allow message > >> access by non-SIP elements, like web-browsers via an App > Server, WAP > etc) > >> > >> and > >> > >> (2) to associate a specific message with a > thread-of-messages - this way > >> if a message arrives using page mode, and a later session > is established > >> and a new message arrives with the same Thread-ID, the UA > knows it is > part > >> of the same session - this also allows muxing multiple > threads within a > >> session without any transport muxing. > >> > >> (of course both IDs are generated by the originating UA, > the two headers > >> should > >> be optional - many apps do not need them). > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:32:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01431 for ; Wed, 24 Oct 2001 10:32:15 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OETePI018169; Wed, 24 Oct 2001 10:29:40 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00772; Wed, 24 Oct 2001 10:31:07 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00761 for ; Wed, 24 Oct 2001 10:30:06 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA01927 for ; Wed, 24 Oct 2001 09:29:44 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 24 Oct 2001 09:22:54 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 09:29:00 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E880613@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , Neil Deason , Brazier Lachlan , "'Jonathan Rosenberg'" , "''SIMPLE Mailinglist' '" Subject: RE: [Simple] Multiple 200 Ok MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15C98.37E56750" X-Orig: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 09:28:58 -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_01C15C98.37E56750 Content-Type: text/plain; charset="iso-8859-1" That'll work. Thanks. Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, October 23, 2001 7:45 PM To: Stucker, Brian [NGB:B621:EXCH]; Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok Another old issue that I want to make sure is closed. Let me summarize the discussion. The question was this: if a PA gets a request, and the request-uri matches that of a user that the PA represents, but the To field doesn't, what do you do? The conclusion of this thread is that it is up to the policy of the PA as to whether it accepts subscriptions that were originally targeted at a different UA (which is what it means when the r-uri and to field don't identify the same user). This is not presence specific at all, as this happens with sip in general when requests are forwarded. The only question was this: what response code to use in this case? I believe 403 is correct; it does not imply that the subscription can never be retried, just that right now, retrying it against this PA won't help any more. Furthermore, this is not presence specific, and belongs in SIP itself. bis-05 actually has a subsection on UAS processing which describes how a uas determines if it should process a request. The section provides response codes to use in specific cases, and this case, and the 403, will be described there. I will also mention this case in the presence spec. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, October 05, 2001 11:10 AM To: Neil Deason; Brazier Lachlan; 'Jonathan Rosenberg'; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok Would it be a 403 forbidden? If a 403 were sent back because the only routable PA wasn't willing to process the subscription, wouldn't this cause the would-be watcher to not try again later when other PA's may be available (via forking) that could process the request? I would think a 404 or a 488 response would be a better fit. ... When is that new events draft going to appear? Until that comes out the NOTIFY with expires = 0 is the way you force-expire a subscription. Regards, Brian -----Original Message----- From: Neil Deason [mailto:ndeason@ubiquity.net] Sent: Friday, October 05, 2001 9:52 AM To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, Brian [NGB:B621:EXCH]; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Hi, > > generally I agree with you about Authorisation and Authentication. > > Let me reformulate the question. Which response do I send back, when I > received a SUBSCRIBE, and I'm not allowed or not willing to be the > presentity (This can happen if someone defines me as > presentity without > letting me know - as the way of authorization is not in the > scope of the > presence draft, errors might happen)? 403 would do. > I have a question concerning the Call flows in the draft. > When a PA receives a SUBSCRIBE with an Expires header, the > response contains > an Expires header as well. What would an Expires header in a > NOTIFY request > sent from the PA to the Watcher mean? Would this update the > subscription > expiration time? > > An example: > userA subscribes for user userB. As userB is a friend of > userA, he accepts > the subscription and the call flows just get on. > After some time userB doesn't want to be the presentity of > userA anymore, or > maybe userB changes the contact information for the SUBSCRIBE > request at > it's registrar. > Now, can userB (better said the PA of userB) send a NOTIFY > with an Expires > header with value 0 to tell userA, that it's subscription > expiration time is > over? > > I think it should be possible to do so, because if not, userB > would need to > wait for the next SUBSCRIBE request from userA, before he can > tell him, that > the subscription time is over. This could be a time value > from seconds to > days, month, years, etc. > > > If there is another mechanism to do so, which one would it be? Maybe a > NOTIFY with an empty body? There current proposal is to use a new header, Subscription-Expires in NOTIFY instead of overloading Expires to indicate when a subscription will end. draft-ietf-simple-presence-03.txt refers to this in describing how PA functionality migrates (5.12). This header still needs to be detailed in a revised 'SIP specific event notification' draft. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net ------_=_NextPart_001_01C15C98.37E56750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Multiple 200 Ok

That'll work.

Thanks.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, October 23, 2001 7:45 PM
To: Stucker, Brian [NGB:B621:EXCH]; Neil Deason; = Brazier Lachlan;
'Jonathan Rosenberg'; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


Another old issue that I want to make sure is = closed.

Let me summarize the discussion. The question was = this: if a PA gets a
request, and the request-uri matches that of a user = that the PA represents,
but the To field doesn't, what do you do? The = conclusion of this thread is
that it is up to the policy of the PA as to whether = it accepts subscriptions
that were originally targeted at a different UA = (which is what it means when
the r-uri and to field don't identify the same = user). This is not presence
specific at all, as this happens with sip in general = when requests are
forwarded. The only question was this: what response = code to use in this
case?

I believe 403 is correct; it does not imply that the = subscription can never
be retried, just that right now, retrying it against = this PA won't help any
more.

Furthermore, this is not presence specific, and = belongs in SIP itself.
bis-05 actually has a subsection on UAS processing = which describes how a uas
determines if it should process a request. The = section provides response
codes to use in specific cases, and this case, and = the 403, will be
described there. I will also mention this case in = the presence spec.

-Jonathan R.



---
Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft        &nbs= p;           &nbs= p;            = East Hanover, NJ 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
http://www.dynamicsoft.com
 
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Friday, October 05, 2001 11:10 AM
To: Neil Deason; Brazier Lachlan; 'Jonathan = Rosenberg'; ''SIMPLE
Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


Would it be a 403 forbidden? If a 403 were sent back = because the
only routable PA wasn't willing to process the = subscription, wouldn't
this cause the would-be watcher to not try again = later when other
PA's may be available (via forking) that could = process the request?
I would think a 404 or a 488 response would be a = better fit.
...
When is that new events draft going to appear? Until = that comes out
the NOTIFY with expires =3D 0 is the way you = force-expire a subscription.
Regards,
Brian
-----Original Message-----
From: Neil Deason [mailto:ndeason@ubiquity.net] =
Sent: Friday, October 05, 2001 9:52 AM
To: Brazier Lachlan; 'Jonathan Rosenberg'; Stucker, = Brian
[NGB:B621:EXCH]; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


> -----Original Message-----
> From: Brazier Lachlan [mailto:lachlan.brazier@siemen= s.at]
>
> Hi,
>
> generally I agree with you about Authorisation = and Authentication.
>
> Let me reformulate the question. Which response = do I send back, when I
> received a SUBSCRIBE, and I'm not allowed or = not willing to be the
> presentity (This can happen if someone defines = me as
> presentity without
> letting me know - as the way of authorization = is not in the
> scope of the
> presence draft, errors might happen)?
403 would do.
> I have a question concerning the Call flows in = the draft.
> When a PA receives a SUBSCRIBE with an Expires = header, the
> response contains
> an Expires header as well. What would an = Expires header in a
> NOTIFY request
> sent from the PA to the Watcher mean? Would = this update the
> subscription
> expiration time?
>
> An example:
> userA subscribes for user userB. As userB is a = friend of
> userA, he accepts
> the subscription and the call flows just get = on.
> After some time userB doesn't want to be the = presentity of
> userA anymore, or
> maybe userB changes the contact information for = the SUBSCRIBE
> request at
> it's registrar.
> Now, can userB (better said the PA of userB) = send a NOTIFY
> with an Expires
> header with value 0 to tell userA, that it's = subscription
> expiration time is
> over?
>
> I think it should be possible to do so, because = if not, userB
> would need to
> wait for the next SUBSCRIBE request from userA, = before he can
> tell him, that
> the subscription time is over. This could be a = time value
> from seconds to
> days, month, years, etc.
>
>
> If there is another mechanism to do so, which = one would it be? Maybe a
> NOTIFY with an empty body?
There current proposal is to use a new header, =
Subscription-Expires in NOTIFY instead of = overloading
Expires to indicate when a subscription will end. =
draft-ietf-simple-presence-03.txt refers to this in =
describing how PA functionality migrates (5.12). = This
header still needs to be detailed in a revised 'SIP =
specific event notification' draft.
Cheers,
Neil.
--
Ubiquity Software Corporation, = UK        http://www.ubiquity.net

------_=_NextPart_001_01C15C98.37E56750-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 10:33:23 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01496 for ; Wed, 24 Oct 2001 10:33:22 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OEUlPI018247; Wed, 24 Oct 2001 10:30:47 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00805; Wed, 24 Oct 2001 10:32:09 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00789 for ; Wed, 24 Oct 2001 10:31:43 -0400 (EDT) Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA02628 for ; Wed, 24 Oct 2001 09:31:21 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 24 Oct 2001 09:24:27 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 09:30:34 -0500 Message-ID: <933FADF5E673D411B8A30002A5608A0E88064F@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , Brazier Lachlan , "Moran Tim (NET/Dallas)" , "adam.roach" , James Undery , "Ngo, Dai (c)" , "'ext Paul Kyzivat'" , Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15C98.6EC03840" X-Orig: Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 09:30:30 -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_01C15C98.6EC03840 Content-Type: text/plain; charset="iso-8859-1" Didn't ever see that this issued was closed by this, or any other suggestion. Where does the 200 vs. 202 debate stand? Thanks, Brian Stucker Nortel Networks -----Original Message----- From: Stucker, Brian [NGB:B621:EXCH] Sent: Tuesday, October 09, 2001 9:51 AM To: Brazier Lachlan; Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 I think I'm seeing the light a bit more... The events draft does state that you need to be ready to get a NOTIFY before the SUBSCRIBE finished (due to dropped packets), so I guess the tag matching isn't so strict on the first NOTIFY, and not having the TO tag from the SUBSCRIBE response isn't considered to be a problem. The text that seems to be causing the confusion is in section 3: "...Once authorized, the presence agent sends a 202 Accepted response. It also sends an immediate NOTIFY message containing the state of the presentity..." The -00 revision of the events draft (unless I'm missing it in my reading) says: 5.1.7.1: "A 202 response indicates that there may be a sizable delay before a notification is received, pending the actual creation of the subscription." 5.1.7.2: "...Upon successful creation or refreshing of a subscription, notifiers MUST send a NOTIFY message as soon as practical to communicate the current resource state to the subscriber...." "...If the response to the SUBSCRIBE message was 202, this initial NOTIFY will serve as indication that the subscription has finally been processed...." Having read it again, I think I now understand what Adam meant by a 3-way handshake, and it does exist in the -00 version of the draft. I think the wording in section 5.1.7.2 does not apply to a NOTIFY that is empty. An empty NOTIFY does not create a subscription (I think). If we look at it this way, then you can see the three-way handshake, and why the empty NOTIFY after a 202 is important after all (just realizing this). The SUBSCRIBE is the first leg of the handshake A->B, the 2xx/empty NOTIFY is the second leg of the handshake B->A, and the response to the empty NOTIFY is the third leg A->B. This makes a ton more sense (at least to me). The wording is a bit vague, but if you take the position that an empty NOTIFY signifies nothing regarding the subscription status, and that the 202 response isn't telling the subscriber that there's going to be a delay before ANY NOTIFY is sent, but instead before a meaningful NOTIFY is sent, then this makes sense. There's even a blurb about getting a NOTIFY with expires=0 after a 202 is to be treated as a 603 decline by the subscriber. So I think this was the behaviour that was intended. Thoughts? Brian ------_=_NextPart_001_01C15C98.6EC03840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Didn't ever see that this issued was closed by this, = or any other suggestion. Where does the 200 vs. 202
debate stand?

Thanks,

Brian Stucker
Nortel Networks
-----Original Message-----
From: Stucker, Brian [NGB:B621:EXCH]
Sent: Tuesday, October 09, 2001 9:51 AM
To: Brazier Lachlan; Moran Tim (NET/Dallas); = adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan = Rosenberg

Cc: simple
Subject: RE: [Simple] 200 vs. 202


I think I'm seeing the light a bit more... The events = draft does state that you need to
be ready to get a NOTIFY before the SUBSCRIBE = finished (due to dropped packets), so I guess
the tag matching isn't so strict on the first = NOTIFY, and not having the TO tag from the
SUBSCRIBE response isn't considered to be a problem. =
The text that seems to be causing the confusion is = in section 3:
"...Once authorized, the presence agent sends a = 202 Accepted response. It also sends an
immediate NOTIFY message containing the state of the = presentity..."
The -00 revision of the events draft (unless I'm = missing it in my reading) says:
5.1.7.1:
"A 202 response indicates that there may be a = sizable delay before a notification
is received, pending the actual creation of the = subscription."
5.1.7.2:
"...Upon successful creation or refreshing of a = subscription,
     notifiers MUST send a = NOTIFY message as soon as practical to
     communicate the current = resource state to the subscriber...."
"...If the response to the SUBSCRIBE message = was 202, this initial
     NOTIFY will serve as = indication that the subscription has finally
     been processed...." =
Having read it again, I think I now understand what = Adam meant by a 3-way handshake, and it
does exist in the -00 version of the draft. I think = the wording in section 5.1.7.2 does not
apply to a NOTIFY that is empty. An empty NOTIFY = does not create a subscription (I think).
If we look at it this way, then you can see the = three-way handshake, and why the empty NOTIFY
after a 202 is important after all (just realizing = this).
The SUBSCRIBE is the first leg of the handshake = A->B, the 2xx/empty NOTIFY is the second leg of
the handshake B->A, and the response to the empty = NOTIFY is the third leg A->B.
This makes a ton more sense (at least to me). The = wording is a bit vague, but if you take the
position that an empty NOTIFY signifies nothing = regarding the subscription status, and that the 202
response isn't telling the subscriber that there's = going to be a delay before ANY NOTIFY is sent, but
instead before a meaningful NOTIFY is sent, then = this makes sense.
There's even a blurb about getting a NOTIFY with = expires=3D0 after a 202 is to be treated as a 603 decline
by the subscriber. So I think this was the behaviour = that was intended.
Thoughts?
Brian

------_=_NextPart_001_01C15C98.6EC03840-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 11:48:26 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04440 for ; Wed, 24 Oct 2001 11:48:26 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OFjkPI019237; Wed, 24 Oct 2001 11:45:46 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01126; Wed, 24 Oct 2001 11:47:08 -0400 (EDT) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01115 for ; Wed, 24 Oct 2001 11:46:44 -0400 (EDT) Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103]) by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA03981 for ; Wed, 24 Oct 2001 10:46:28 -0500 (CDT) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 24 Oct 2001 10:44:12 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Oct 2001 10:45:29 -0500 Message-ID: From: "Sriram Parameswar" To: "'Jonathan Rosenberg'" , "Brian Stucker" , Brazier Lachlan , "''Neil Deason' '" , "''SIMPLE Mailinglist' '" Subject: RE: [Simple] Multiple 200 Ok MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C15CA2.E6938750" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 10:45:26 -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_01C15CA2.E6938750 Content-Type: text/plain; charset="iso-8859-1" Even the RPI may be blocked by Proxies that do not trust the preceding proxy. So we may not have solved the issue fully. Regards, Sriram __________________________________________ Sriram Parameswar Phone: 972-685-8540 Interactive Multimedia Server (IMS) Fax: 972-685-3563 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, October 23, 2001 7:45 PM To: Stucker, Brian [NGB:B621:EXCH]; Jonathan Rosenberg; Brazier Lachlan; Jonathan Rosenberg; ''Neil Deason' '; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok Another old thread. The issue was how a subscriber knows the identity of the actual PA which answered the SUBSCRIBE, since it may have been forwarded. Response inline. -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, October 05, 2001 11:02 AM To: Jonathan Rosenberg; Brazier Lachlan; Jonathan Rosenberg; ''Neil Deason' '; ''SIMPLE Mailinglist' ' Subject: RE: [Simple] Multiple 200 Ok >I'm a bit worried about using the contact header in the 2xx as a means of >identifying the user that processed the SUBSCRIBE. The watcher has no method >of determining the user's contact list to check the contact received >against. So I don't see a reliable method of taking a contact and determining >the user that contact is for unless you're the registrar (and even then it >can be ambiguous). If you have a proxy that straddles a firewall, it will >probably modify the contact address in the 2xx response, so the contact returned >may be one that only the proxy knows who it maps to, and nobody else. I agree that Contact is far from ideal. Remote-Party-ID is really much better, since it provides a logical identity, and thats exactly what you want. I don't want to mandate the usage of R-PID for this, as it introduces a dependency. So, I will simply indicate that the privacy spec can be used if you want to provide the identity of the PA which actually answered. This makes the reference non-normative and therefore there is no dependency. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C15CA2.E6938750 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Multiple 200 Ok

Even the RPI may be blocked by Proxies that do not = trust the preceding proxy. So we may not have solved the issue = fully.

Regards,

Sriram
__________________________________________
Sriram = Parameswar          &n= bsp;   Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: = 972-685-3563
Nortel Networks, Richardson USA  Email: = sriramp@nortelnetworks.com


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, October 23, 2001 7:45 PM
To: Stucker, Brian [NGB:B621:EXCH]; Jonathan = Rosenberg; Brazier Lachlan;
Jonathan Rosenberg; ''Neil Deason' '; ''SIMPLE = Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


Another old thread. The issue was how a subscriber = knows the identity of the
actual PA which answered the SUBSCRIBE, since it may = have been forwarded.

Response inline.

 
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Friday, October 05, 2001 11:02 AM
To: Jonathan Rosenberg; Brazier Lachlan; Jonathan = Rosenberg; ''Neil Deason'
'; ''SIMPLE Mailinglist' '
Subject: RE: [Simple] Multiple 200 Ok


>I'm a bit worried about using the contact header = in the 2xx as a means of
>identifying the user that processed the = SUBSCRIBE. The watcher has no
method
>of determining the user's contact list to check = the contact received
>against. So I don't see a reliable method of = taking a contact and
determining
>the user that contact is for unless you're the = registrar (and even then it
>can be ambiguous). If you have a proxy that = straddles a firewall, it will
>probably modify the contact address in the 2xx = response, so the contact
returned
>may be one that only the proxy knows who it maps = to, and nobody else.

I agree that Contact is far from ideal.

Remote-Party-ID is really much better, since it = provides a logical identity,
and thats exactly what you want.

I don't want to mandate the usage of R-PID for this, = as it introduces a
dependency. So, I will simply indicate that the = privacy spec can be used if
you want to provide the identity of the PA which = actually answered. This
makes the reference non-normative and therefore = there is no dependency.

-Jonathan R.


---
Jonathan D. Rosenberg, Ph.D.    &= nbsp;           72 = Eagle Rock Ave.
Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
dynamicsoft        &nbs= p;           &nbs= p;            = East Hanover, NJ 07936
jdrosen@dynamicsoft.com      &nbs= p;           &nbs= p;  FAX:   (973) 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
simple mailing list
simple@mailman.dynamicsoft.com
http://mailman.dynamicsoft.com/mailman/listinfo/simple=

------_=_NextPart_001_01C15CA2.E6938750-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 13:19:44 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07269 for ; Wed, 24 Oct 2001 13:19:44 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OHH5PI020519; Wed, 24 Oct 2001 13:17:05 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01491; Wed, 24 Oct 2001 13:18:08 -0400 (EDT) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01478 for ; Wed, 24 Oct 2001 13:17:05 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f9OHGff02933 for ; Wed, 24 Oct 2001 13:16:45 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <4C4S1TG7>; Wed, 24 Oct 2001 18:16:33 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3418@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Brazier Lachlan , simple@mailman.dynamicsoft.com, "'Jonathan Rosenberg'" Subject: RE: [Simple] Contact header in MESSAGE request MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 18:16:31 +0100 Jonathan states that there is no Reply-To header in SIP. I would note that one of the forms of the Remote-Party-ID header (privacy draft) is to provide an address for returning a call to, rather than this is the address that made the call. Current definition as follows: Return session identity (rpi-id-type="return") This identifies the point to which the party wishes return sessions to be addressed. For example a business may wish to provide a 'freephone' identity to encourage return calls. If absent, this is assumed to be the same as the subscriber identity. From the discussion I have read, surely this would fulfil the function rather than inventing a new header. It would of course mean extenting the usage of the Remote-Party-ID to another method. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Jonathan Rosenberg[SMTP:jdrosen@dynamicsoft.com] > Sent: 23 October 2001 2:13 > To: Brazier Lachlan; simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Contact header in MESSAGE request > > > > > > > -----Original Message----- > > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Sent: Tuesday, October 16, 2001 3:48 AM > > To: simple@mailman.dynamicsoft.com > > Subject: [Simple] Contact header in MESSAGE request > > > > > > Hello, > > > > I've been reading draft-ietf-simple-im-01, and at the end I > > read Appendix A. > > Requirements Evaluation. > > > > "Requirement 4.1.3. The common message format MUST include a return > > address for the receiver to reply to the sender with another > > INSTANT MESSAGE." This is done through the Contact headers > > defined in SIP. > > > > Does this mean that the Contact header is mandatory in an > > MESSAGE request? > > It's not according to the table of header fields. > > This is something that has changed a bit as the session model has evolved > into a separate entity. The initial model was that MESSAGE itself set up a > session, but this was discarded as we didn't want multiple ways to > establish > an interaction communicastions session, and certainly voice/video could be > part of that. In this initial model, since MESSAGE was like INVITE, it had > a > Contact header that was used for sending subsequent messages within the > session. > > Then, with the paging model, MESSAGE became a "one-shot" kind of thing. > There is no session or context for the messages. Since Contact is meant to > provide an endpoint address, its not very useful for paging mode. In these > cases, you can't really provide a a host address, since these things > change, > and the duration during which that address would remain useful is unknown. > Providing a direct host address is only useful where there is a session, > and > we can change it if the host moves (SIP provides this ability). So, > Contact > doesn't make sense anymore. Thats why its not in the table. > > However, one might want to provide a reply address that isn't a host IP or > hostname. Rather, we want to provide a logical address to send messages in > reply. Normally, the From is used for this kind of thing, but certainly > the > address for sending a response could be something else. > > Right now, there is no Reply-To header in SIP. It would be a useful thing > to > have, as it makes sense for initiating calls as well (If I call you, and > you're not there, I can provide a logical address to use to call me back > at > any point later on). In fact, this is a current open issue in the bis > specification itself (whether or not to add a Reply-To address). Oddly, > bis > does have an In-Reply-To header that identifies the specific call that a > new > call is in reply to. > > Since we have multiple cases where it is needed, sounds like its something > that should be added. > > -Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 18:01:39 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15189 for ; Wed, 24 Oct 2001 18:01:34 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OLwKPI023918; Wed, 24 Oct 2001 17:58:20 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02425; Wed, 24 Oct 2001 17:59:08 -0400 (EDT) Received: from localhost.localdomain ([63.110.3.137]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02408; Wed, 24 Oct 2001 17:58:17 -0400 (EDT) Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f9OLrv101988; Wed, 24 Oct 2001 16:53:57 -0500 Message-ID: <3BD73874.2040702@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Gur_Kimchi@vocaltec.com CC: Jonathan Rosenberg , Paul Kyzivat , Avshalom@ubique.com, "'Rosen, Brian'" , Henning Schulzrinne , "'Christian Huitema'" , "Peterson, Jon" , "Roy, Radhika R, ALCTA" , simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com, Vasilis Polychronidis Subject: Re: [Simple] IM over the signaling connection References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 16:53:56 -0500 Content-Transfer-Encoding: 7bit If we had those headers, would you expect them to be in SIP headers or in the meta-data of message/cpim? It seems to me the second makes more sense, as this is information that may need to be delivered end-to-end across a CPIM boundery. Gur_Kimchi@vocaltec.com wrote: > Jonathan - > > I agree we should not hold up the basic page mode - but I feel the ability > to associate MESSAGEs with a "thread of MESSAGES" is needed regardless if > it in a page or in an INVITE-established session - again I am not asking > for > anything mandatory - but I do feel unique optional and > > headers should be in the draft now. > > I think the use of these optional headers (+In-Reply-To) is obvious, and > documenting them should not be controversial - but I have been wrong > before... > > at the same time, I have not heard an objection yet to their inclusion. > > - gur > > >>>-Jonathan R. Wrote: >>> >>>One thing I do want to note.... I think that whatever we do for thread >>> > IDs, > >>>in-reply-to's or whatever should not hold up the basic paging model. All >>> > of > >>>those things are primarily needed to facilitate integration with a >>> > session > >>>model, and therefore we should worry about those things later. Lets get >>> > the > >>>basic paging model done. >>> > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 18:16:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15361 for ; Wed, 24 Oct 2001 18:16:17 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OMDkPI024106; Wed, 24 Oct 2001 18:13:46 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02527; Wed, 24 Oct 2001 18:15:10 -0400 (EDT) Received: from localhost.localdomain ([63.110.3.137]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02514 for ; Wed, 24 Oct 2001 18:14:37 -0400 (EDT) Received: from dynamicsoft.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id f9OM9m102040; Wed, 24 Oct 2001 17:09:48 -0500 Message-ID: <3BD73C2C.7060701@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010914 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Hammer CC: Christian Huitema , "Roy, Radhika R, ALCTA" , Vasilis Polychronidis , Jonathan Rosenberg , Henning Schulzrinne , "Peterson, Jon" , Avshalom@ubique.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] IM over the signaling connection References: <4.3.2.7.2.20011009162017.00b05818@cia.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Wed, 24 Oct 2001 17:09:48 -0500 Content-Transfer-Encoding: 7bit I think I should have said "series" of messages, rather than "stream" of messages, because I think I conveyed the wrong idea. The current draft assumes a one to one correspondence between MESSAGE requests and IMs. It does mention that if you want to send something larger than the maximum UDP size, you should use TCP. If we are talking about MESSAGE as a file transfer protocol, I think this would be better modeled using an INVITE initiated file transfer session of some sort. Michael Hammer wrote: > Ben, > > Whether a message appears as a single IM or a stream of IM right now > appears to be more of an implementation detail, absent a maximum IM > size. (Did I miss that definition?) Given that an application may send > a 1 Mbyte message as: > > 1) one 1 M IM, > 2) two 512 K IMs, > 3) four 256 K IMs, > ... > n-2) 256 4 K IMs > n-1) 512 2 K IMs > n) 1024 1K IMs > > Does IM size count at all or just message and response counts? > Do we care that SIP may need to segment to some max message size, say > 1500 bytes? > Do we care that a lower layer may need to segment the message prior to > transmission? > Do we care if the IP layer has to fragment during transmission? > Are there some unstated assumptions in your calculation? > > Mike > > > At 02:39 PM 10/9/2001 -0500, Ben Campbell wrote: > >> I agree with Christian here--I really want to discourage session mode >> unless one expects a stream of messages. One shot text messages should >> normally be page mode. >> >> Christian Huitema wrote: >> >>> Note that my point was not to ignore the lessons of the past, but to >>> point out that widely deployed systems such as SMS are not going to >>> disappear in a day, or in a year -- they are with us for at least one >>> or two upgrade cycles, i.e. at least 4 to 6 years. >>> >>> Also note that if the usage is actually a page, then a "message" is >>> less taxing on the infrastructure than an "invite" + the necessary >>> session clean-up. Let's compare: >>> >>> 1) Message: one signalling message + one response per IM. >>> >>> 2) Session: INVITE + response; ACK; BYE+response; + additional cost >>> of setting the message channel; IM messages on channel. >>> >>> From a pure signalling point of view, the session mode is only >>> beneficial when there are at least 3 IM exchanged in a session. >>> >>> -- Christian Huitema >>> >>> -----Original Message----- >>> *From:* Roy, Radhika R, ALCTA [mailto:rrroy@att.com] >>> *Sent:* Tuesday, October 09, 2001 6:23 AM >>> *To:* Vasilis Polychronidis; Christian Huitema >>> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; >>> Peterson, Jon; Avshalom@ubique.com; simple@mailman.dynamicsoft.com >>> *Subject:* RE: [Simple] IM over the signaling connection >>> Hi, Vasilis: >>> >>> Good that you have reminded the very important lesson from the past. >>> >>> Would please let us know your opinion what do we do in the case of >>> "Paging" in SIP? >>> >>> Of course, we have another scheme: MESSAGE as session. >>> >>> Radhika >>> -----Original Message----- >>> *From:* Vasilis Polychronidis >>> [mailto:Vasilis.Polychronidis@openwave.com] >>> *Sent:* Monday, October 08, 2001 4:43 PM >>> *To:* Christian Huitema >>> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; >>> Peterson, Jon; Avshalom@ubique.com; >>> simple@mailman.dynamicsoft.com >>> *Subject:* Re: [Simple] IM over the signaling connection >>> Christian Huitema wrote: >>> There are two points that I keep in mind in this debate: >>> 1) SMS, the messaging service of cell phones, uses the page >>> mode and is >>> carried at least in part over the signaling channel. >>> Correct. However Operators realized that SMS was the wrong (was >>> very successful financially) technical solution for messaging. >>> Remind you that when the people designed (late 80s) SMS they did >>> not have any idea of how successful commercial service will be. >>> That is why the next generation of multimedia messaging is using >>> HTTP as the transport. >>> I understand that this is a difficult point to understand with >>> some people in the list. >>> Let me remind you that the telephony people with more than >>> hundred years of experience realized in the late seventies that >>> in order to scale and have very reliable networks you had to >>> separate signaling from transport (initially signaling was mixed >>> with transport - >>> that is the current case for all the analog lines going from >>> home to the local switch --> DTMF) and they created SS7 and >>> ISUP. >>> Actually people invented SIP using ISUP as their guide. >>> That was one of the initial arguments of SIP: separate proxies >>> from transport of user data. >>> It seems to me that certain people want to regress in time and >>> mix signaling and user data. >>> Let us please learn from the history and lets try not to repeat >>> the same mistakes. >>> >>> 2) CPIM's Message function looks a lot like the page mode. >>> It seems that the first step forward is to recognize this >>> and assume >>> that we will indeed use "MESSAGE over SIP" in the page mode >>> for a >>> significant fraction of our exchanges. I suggest that the >>> first order >>> action of SIMPLE is to just nail this one, so it be >>> behind us. >>> The page mode has well known limitations: it creates a lot >>> of overhead >>> in long sessions, and it does not extend easily to >>> multi-party >>> operation. This is the rationale for the "IM session" >>> extensions, i.e. >>> IM after INVITE. However, whatever we do in the session >>> mode, we will >>> have to go on interworking with SMS and with CPIM; this >>> means that we >>> will have to bring in the session some members who can only >>> use the page >>> mode. Obviously, a "session of messages" makes this very >>> easy. >>> -- Christian Huitema >>> _______________________________________________ >> >> >> >> >> _______________________________________________ >> simple mailing list >> simple@mailman.dynamicsoft.com >> http://mailman.dynamicsoft.com/mailman/listinfo/simple > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Oct 24 18:50:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16097 for ; Wed, 24 Oct 2001 18:50:12 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9OMljPI024356; Wed, 24 Oct 2001 18:47:45 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02700; Wed, 24 Oct 2001 18:49:11 -0400 (EDT) Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02687; Wed, 24 Oct 2001 18:48:36 -0400 (EDT) From: Gur_Kimchi@vocaltec.com Subject: Re: [Simple] IM over the signaling connection To: Ben Campbell Cc: Jonathan Rosenberg , Paul Kyzivat , Avshalom@ubique.com, "'Rosen, Brian'" , Henning Schulzrinne , "'Christian Huitema'" , "Peterson, Jon" , "Roy, Radhika R, ALCTA" , simple@mailman.dynamicsoft.com, simple-admin@mailman.dynamicsoft.com, Vasilis Polychronidis X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 10/24/2001 06:47:25 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 25 Oct 2001 01:47:17 +0200 >> Ben Campbell Wrote: >> >> If we had those headers, would you expect them to be in SIP headers or >> in the meta-data of message/cpim? It seems to me the second makes more >> sense, as this is information that may need to be delivered end-to-end >> across a CPIM boundery. out of the two choices It does makes more sense to put it into the individual cpim header - with multipart mime I could see multiple messages in one MESSAGE body (think forwarding/aggregating proxy). >> Ben Campbell Wrote: >> >> I think I should have said "series" of messages, rather than "stream" of >> messages, because I think I conveyed the wrong idea. The current draft >> assumes a one to one correspondence between MESSAGE requests and IMs. It >> does mention that if you want to send something larger than the maximum >> UDP size, you should use TCP. >> >> If we are talking about MESSAGE as a file transfer protocol, I think >> this would be better modeled using an INVITE initiated file transfer >> session of some sort. There is no problem limiting the size of IMs to some very small size- the usual solution when needing to send large amounts of data is to send "by reference" - e.g. send a URL to the file you want the other side to get, instead of the file itself. I see no problem with limiting sizes of IMs to under 512 bytes, allowing both UDP and TCP to be used. remember that on the largest IM system in the world (GSM-SMS) the maximum size is 160 chars - I dont think we are here to solve file/image/XYZ transfer problems, if you want to send anything that is not an IM (and the definition is clear) - INVITE to a specific-media session or MESSAGE a URL of where the resource can be found. (http://www1.ics.uci.edu/pub/ietf/uri/draft-antti-gsm-sms-url-04.txt) - gur _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Oct 25 11:05:56 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21184 for ; Thu, 25 Oct 2001 11:05:55 -0400 (EDT) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f9PF3XPI027859; Thu, 25 Oct 2001 11:03:33 -0400 (EDT) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05693; Thu, 25 Oct 2001 11:04:16 -0400 (EDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05682 for ; Thu, 25 Oct 2001 11:03:53 -0400 (EDT) Received: from libero.it (193.70.192.41) by smtp3.libero.it (6.0.032) id 3BD43E25000FE192 for simple@mailman.dynamicsoft.com; Thu, 25 Oct 2001 17:03:17 +0200 Message-Id: MIME-Version: 1.0 Content-Type: text/plain From: "sal" To: simple@mailman.dynamicsoft.com X-XaM3-API-Version: 1.1.9.1.39.1.2 X-SenderIP: 193.205.164.115 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id LAA05682 Subject: [Simple] upload Presence Document Sender: simple-admin@mailman.dynamicsoft.com Errors-To: simple-admin@mailman.dynamicsoft.com X-BeenThere: simple@mailman.dynamicsoft.com X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: SIP for Presence List-Unsubscribe: , List-Archive: Date: Thu, 25 Oct 2001 17:03:17 +0200 Content-Transfer-Encoding: 8bit in the scenario "Presence Server Notification", how the PresenceServer/PA receive the presence document from the PUA? Is it possible that the PUA send the presence document as body of the REGISTER request? or exists other possibility? Salvatore Loreto _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple