From simple-admin@mailman.dynamicsoft.com Thu Nov 1 02:48:11 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28734 for ; Thu, 1 Nov 2001 02:48:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA17iib7022987; Thu, 1 Nov 2001 02:44:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12612; Thu, 1 Nov 2001 02:46:02 -0500 (EST) Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12600 for ; Thu, 1 Nov 2001 02:45:36 -0500 (EST) Received: from blazer (localhost.localdomain [127.0.0.1]) by bdsl.66.12.12.130.gte.net (8.11.2/8.11.2) with SMTP id fA17pMD18618; Thu, 1 Nov 2001 01:51:23 -0600 Message-ID: <006001c1629f$ff569130$55fa403f@blazer> From: "Dean Willis" To: "sal" , References: Subject: Re: [Simple] upload Presence Document MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 1 Nov 2001 00:39:45 -0600 Content-Transfer-Encoding: 7bit There has been some discussion of an "Upload" method. Of coure, one could push the presence doc via another protocol, such as HTTP POST. -- Dean ----- Original Message ----- From: "sal" To: Sent: Thursday, October 25, 2001 9:03 AM Subject: [Simple] upload Presence Document > 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 > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 05:00:25 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08726 for ; Thu, 1 Nov 2001 05:00:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA19whb7023290 for ; Thu, 1 Nov 2001 04:58:43 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13120 for ; Thu, 1 Nov 2001 05:00:15 -0500 (EST) Date: Thu, 1 Nov 2001 05:00:15 -0500 (EST) Message-Id: <200111011000.FAA13120@mailman.dynamicsoft.com> Subject: mailman.dynamicsoft.com mailing list memberships reminder From: mailman-owner@mailman.dynamicsoft.com To: simple-archive@ietf.org X-No-Archive: yes X-Ack: no 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 This is a reminder, sent out once a month, about your mailman.dynamicsoft.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, simple-request@mailman.dynamicsoft.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@mailman.dynamicsoft.com. Thanks! Passwords for simple-archive@lists.ietf.org: List Password // URL ---- -------- simple@mailman.dynamicsoft.com ifheto http://mailman.dynamicsoft.com/mailman/options/simple/simple-archive%40lists.ietf.org From simple-admin@mailman.dynamicsoft.com Thu Nov 1 05:57:34 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09905 for ; Thu, 1 Nov 2001 05:57:34 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1AsVb7025162; Thu, 1 Nov 2001 05:54:31 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15767; Thu, 1 Nov 2001 05:56:02 -0500 (EST) 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 FAA15756 for ; Thu, 1 Nov 2001 05:55:45 -0500 (EST) Received: from libero.it (193.70.192.61) by smtp3.libero.it (6.0.032) id 3BD43E25002FA055; Thu, 1 Nov 2001 11:55:23 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?utf-8?Q?sal?=" To: dean.willis@softarmor.com Cc: simple@mailman.dynamicsoft.com X-XaM3-API-Version: 2.5 X-type: 0 X-SenderIP: 213.213.12.225 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id FAA15756 Subject: [Simple] =?iso-8859-1?Q?Re:_[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, 1 Nov 2001 11:55:23 +0100 Content-Transfer-Encoding: 8bit i think that the Presence Document could be insert in a SIP message... of course REGISTER haven't a body... but after a PUA send a register to a PA (presence server) this server could send a request message to the PUA for receive the Presence Document... just for example (i know that's not correct) PUA send REGISTER to PA... when the PA accept the register, end register is end, PA send SUBSCRIBE (particular) to PUA end receive a NOTIFY (particular) with a document presence... > > There has been some discussion of an "Upload" method. Of coure, one could > push the presence doc via another protocol, such as HTTP POST. > > -- > Dean > > ----- Original Message ----- > From: "sal" > To: > Sent: Thursday, October 25, 2001 9:03 AM > Subject: [Simple] upload Presence Document > > > > 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 > > > > > > _______________________________________________ > 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 Thu Nov 1 07:08:45 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11419 for ; Thu, 1 Nov 2001 07:08:44 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1C5jb7025331; Thu, 1 Nov 2001 07:05:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16006; Thu, 1 Nov 2001 07:07:09 -0500 (EST) 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 HAA15994 for ; Thu, 1 Nov 2001 07:06:15 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [63.113.40.50]) with SMTP; 1 Nov 2001 12:06:04 UT Received: from neil ([193.195.52.214]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Nov 2001 12:08:00 +0000 From: "Neil Deason" To: "Dean Willis" , "sal" , Subject: RE: [Simple] upload Presence Document Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <006001c1629f$ff569130$55fa403f@blazer> Importance: Normal X-OriginalArrivalTime: 01 Nov 2001 12:08:00.0575 (UTC) FILETIME=[D9D88CF0:01C162CD] 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, 1 Nov 2001 12:07:58 -0000 Content-Transfer-Encoding: 7bit There is also the idea of a general-purpose SIP mechanism for uploading service related data as discussed in: http://search.ietf.org/internet-drafts/draft-donovan-publish-requirement s-00.txt Unfortunately there has not been much comment on this since publication. It is certainly a better mechanism than over-loading REGISTER for CPL uploads. People already do that even though it is ugly so there is desire for a SIP based solution. You could even imagine a location service that allows a UA to publish a XML location document essentially deprecating REGISTER. Cheers, Neil -- Ubiquity Software Corporation, UK http://www.ubiquity.net > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Dean Willis > Sent: 01 November 2001 06:40 > To: sal; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] upload Presence Document > > > > There has been some discussion of an "Upload" method. Of > coure, one could > push the presence doc via another protocol, such as HTTP POST. > > -- > Dean > > ----- Original Message ----- > From: "sal" > To: > Sent: Thursday, October 25, 2001 9:03 AM > Subject: [Simple] upload Presence Document > > > > 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 > > > > > > _______________________________________________ > 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 Thu Nov 1 11:34:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23171 for ; Thu, 1 Nov 2001 11:34:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1GVeb7027352; Thu, 1 Nov 2001 11:31:40 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16828; Thu, 1 Nov 2001 11:33:05 -0500 (EST) Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16782 for ; Thu, 1 Nov 2001 11:27:47 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-32 #42257) with ESMTP id <0GM400EBXR1PK0@firewall.wcom.com> for simple@mailman.dynamicsoft.com; Thu, 1 Nov 2001 16:27:26 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GM400G01R1F6W@dgismtp01.wcomnet.com>; Thu, 01 Nov 2001 16:27:24 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GM400EJHR104P@dgismtp01.wcomnet.com>; Thu, 01 Nov 2001 16:27:01 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Thu, 01 Nov 2001 16:27:00 +0000 Content-return: allowed From: "Ngo, Dai (c)" Subject: RE: [Simple] 200 vs. 202 To: "'Brian Stucker'" , "'Brazier Lachlan'" , "Moran Tim (NET/Dallas)" , "adam.roach" , James Undery , "'ext Paul Kyzivat'" , Jonathan Rosenberg Cc: simple Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E6B@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: multipart/alternative; boundary="Boundary_(ID_/NWvrnzbd7ZskUDr8oS+Cg)" 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, 01 Nov 2001 16:26:58 +0000 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. --Boundary_(ID_/NWvrnzbd7ZskUDr8oS+Cg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in= the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, = the subscription moves into the pending state. In this state, the server = is awaiting an authorization decision. *No notifications are generated*,= but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are = saying here, that an empty notification is needed to complete the three-ways handshake. =20 How do we reconcile this conflict? =20 -- Dai =20 =20 =20 -----Original Message----- =46rom: Brian Stucker [mailto:bstucker@nortelnetworks.com]=20 Sent: Tuesday, October 09, 2001 2:27 PM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roa= ch; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 =20 Maybe the confusion that we're having is centered around how to deal = with an empty NOTIFY. If you think of an empty NOTIFY as signifying nothing a= bout the=20 status of the subscription (pending or accepted) and nothing about th= e state of the resource the subscription is made to (in this case the presenc= e agent),=20 then things get a lot simpler.=20 If you think about it that way, then the processing of an empty NOTIF= Y creates=20 a three-way handshake to the subscription request, and that helps wit= h forking=20 issues.=20 If the events draft is updated to clarify this thinking (assuming tha= t this is=20 the behaviour desired), and the presence draft is updated such that a= n *empty*=20 NOTIFY, and not one with bogus information in it, is sent after a 202= , then I=20 think things will get a lot less fuzzy.=20 Jonathan? Adam?=20 Brian=20 -----Original Message-----=20 =46rom: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com ]=20 Sent: Tuesday, October 09, 2001 8:32 AM=20 To: 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran Tim=20 (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan= =20 Rosenberg=20 Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 =20 In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-= 00.txt=20 =66rom Adam Roach, it states, "When a SUBSCRIBE request is successful= ly=20 processed or a relevant change in the subscribed state occurs, the no= tifier=20 will construct and send a NOTIFY request to the subscribers, as speci= fied in the contact field of the SUBSCRIBE request. Such a message should be = sent in as timely a manner as is practical".=20 In section 5.8 "Notifier Generation of NOTIFY Requests" of=20 draft-ietf-simple-presence-03.txt it states, "If a subscription is ac= cepted=20 (or politely blocked) a NOTIFY must be sent after the 200 OK response= to the SUBSCRIBE has been sent. Notifications MAY be sent at later times, po= ssibly=20 when the presence state of the presentity changes."=20 It makes more sense to NOT sending the empty NOTIFY after a 202.=20 Regards,=20 -- Dai Ngo=20 -----Original Message-----=20 =46rom: Brazier Lachlan [mailto:lachlan.brazier@siemens.at ]=20 Sent: Tuesday, October 09, 2001 3:29 AM=20 To: 'Brian Stucker'; Moran Tim (NET/Dallas); adam.roach; James Undery= ; Ngo,=20 Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg=20 Cc: simple=20 Subject: AW: [Simple] 200 vs. 202=20 Hello,=20 =20 When a subscriber receives a 200 on a SUBSCRIBE request, a NOTIFY fro= m the=20 presentity can be handled. NOTIFY's from other senders will be respon= ded to=20 with an error (481). The tags in the FROM header of these NOTIFY's ar= e=20 different than the tag in the To header in the response to the SUBSCR= IBE.=20 =20 When a subscriber receives a 202 on a SUBSCRIBE request, a NOTIFY fro= m the=20 presentity can be handled. NOTIFY's from other senders will be respon= ded to=20 with an error (481). The tags in the FROM header of these NOTIFY's ar= e=20 different than the tag in the To header in the response to the SUBSCR= IBE.=20 =20 =20 The question is now, when is the presentity sending the NOTIFY?=20 =20 If a 200 Ok was returned to the SUBSCRIBE request, the PA of the pres= entity=20 knows the status of the presentity. If a 202 Accepted was returned, i= t=20 doesn't know right now, but it can find out.=20 =20 I believe that a NOTIFY must be sent "immediately" after sending a 2x= x=20 response to the subscriber. What does "immediately mean"? Does it mea= n=20 sending the NOTIFY without delay, or does it mean sending the NOTIFY = when=20 the status is obtained by the PA?=20 =20 If "immediately" means after obtaining the status, I don't see the pr= oblem.=20 =20 If "immediately" means without delay, the first NOTIFY after sending = a 202=20 will be useless. I've looked in the presence draft=20 (draft-ietf-simple-presence-03.txt), but I haven't found the phrase s= tating, that a NOTIFY MUST be sent immediately after sending a 202 Acepted. I= only=20 found it for 200 Ok.=20 Still, as 202 Accepted is a positive response, the NOTIFY could be re= quired. This leads to my next question: Why is it required?=20 Anyway, to follow the requirements, I always can send an empty NOTIFY= .=20 =20 =20 Please correct me, when I stated something wrong or missunderstood= =20 something!=20 =20 Lachlan=20 =20 =20 -----Urspr=FCngliche Nachricht-----=20 Von: Brian Stucker [mailto:bstucker@nortelnetworks.com ]=20 Gesendet am: Dienstag, 09. Oktober 2001 01:34=20 An: Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); '= ext=20 Paul Kyzivat'; Jonathan Rosenberg=20 Cc: simple=20 Betreff: RE: [Simple] 200 vs. 202=20 =20 It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, = the=20 watcher must reject the subsequent NOTIFY because it never saw what t= he TO=20 tag was from the response to the SUBSCRIBE (because it was in the 200= OK).=20 You could argue that the watcher takes the TO tag in the first respon= se or=20 NOTIFY it gets back (as long as the FROM tag and everything else matc= hes=20 ok). However, that seems to be a bit dangerous if we consider cases w= here=20 multiple packets are being dropped (unintentionally or otherwise).= =20 Forking subscriptions seems to be problematic at best unless you ACK = the=20 response (as Adam pointed out with the 3-way handshake mention) like = an=20 INVITE does instead of relying on a NOTIFY that does nothing because = CPIM=20 wants it. It's coming from the wrong endpoint, as you say. I would th= ink=20 that anything that forks, and creates a meta-session routing requirem= ent=20 needs to be ACK'd.=20 Brian Stucker=20 =20 -----Original Message-----=20 =46rom: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com =20 > ]=20 Sent: Monday, October 08, 2001 6:17 PM=20 To: adam.roach; Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Da= i (c);=20 'ext Paul Kyzivat'; Jonathan Rosenberg=20 Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 =20 Three-way handshake in my dictionary implies A->B, A<-B, and then a A= ->B=20 again. This is not the case in a Subscribe, 200/202 and then a Notify= in=20 the same direction as the 2xx.. I am also puzzled by your "immediate"= =20 requirement after a 202 since your own draft uses phrases like ...= =20 A 202 response indicates that there may be a sizable delay before a= =20 notification is received, pending the actual creation of the subscrip= tion=20 If the notifier owner is interactively queried to determine whether a= =20 subscription is allowed, a "202 Accept" response is returned immediat= ely,=20 and the subsequent NOTIFY request is suppressed until the notifier o= wner=20 responds.=20 Does the requirement for an immediate notify after a 202 only apply t= o=20 forked requests? How does the server know when a request has been for= ked?=20 So let's say a Subscribe is forked and all the PAs respond with 202. = The=20 best one is returned to the watcher and the rest dropped. All of the = PAs=20 must also respond with a Notify with useless information which the pr= oxy=20 passes on. How enlightened is the watcher upon receiving the dummy= =20 Notifications? What change is there in the state machine? Then there = is the=20 scenario of 202s come back, proxy timer expires so the best 202 is se= nt back to watcher - and then a 200 comes. I presume it would be dropped. The= PA=20 which sent the 200 sends a Notify (immediately) which is forwarded bu= t there is no preceding 200 so the watcher drops it? There is the out-of-seq= uence=20 clause, but if the 200 never appears wouldn't the notify be rejected?= Nodes=20 which know they can't authorize at the time of subscription may respo= nd=20 quicker than the node which is actually doing the work of obtaining= =20 authorization. Sounds like some guidelines are needed as to how fast = is=20 immediate and how long a proxy waits for that 200 with the immediate = notify. Tim M.=20 > -----Original Message-----=20 > From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com =20 > ]= =20 > Sent: Monday, October 08, 2001 2:12 PM=20 > To: 'Brian Stucker'; James Undery; Ngo, Dai (c); Moran Tim=20 > (NET/Dallas);=20 > 'ext Paul Kyzivat'; Jonathan Rosenberg=20 > Cc: simple=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > Sorry; I haven't been following this closely (things have been=20 > hellishly busy recently). This conversation, though, seems to=20 > have taken a dangerous turn.=20 >=20 > Remember that the behaviour of SUB/NOT is general, and not just= =20 > related to presence. And, in the general case, forking of SUBSCRIBE= s=20 > can be extremely useful.=20 >=20 > However, without a three-way handshake, such forking becomes quite= =20 > messy and unpleasant to implement.=20 >=20 > The immediate NOTIFY is the third message of this three-way handsha= ke.=20 > It can't be removed from the base SUB/NOT draft; by extension, the = use=20 > of SUB/NOT for presence needs to keep it.=20 >=20 > /a=20 >=20 >=20 > -----Original Message-----=20 > From: Brian Stucker [ mailto:bstucker@nortelnetworks.com =20 > ] > Sent: Monday, October 08, 2001 1:54 PM=20 > To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)';=20 > 'ext Paul Kyzivat';=20 > Jonathan Rosenberg=20 > Cc: simple=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > Ok, as a compromise, since we all seem to feel that the=20 > NOTIFY after a 202 is=20 > totally useless...=20 > Can't we make the 202 act as an implied 'Offline' (or some=20 > other harmless, and=20 > meaningless indication)=20 > NOTIFY within the context of how CPIM requirements work in a=20 > SIP network?=20 > Gateway functions to other=20 > protocols can generate whatever messages they want from this,=20 > but in the=20 > context of what gets sent=20 > around in a SIP network, the 202 acts as a NOTIFY itself.=20 > Heck, you could even put dummy XML in the 202 message body if=20 > you really wanted=20 > (but I'd rather not).=20 > Brian Stucker=20 > -----Original Message-----=20 > From: James Undery [ mailto:jundery@ubiquity.net =20 > ]=20 > Sent: Monday, October 08, 2001 5:12 AM=20 > To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul=20 > Kyzivat'; Jonathan=20 > Rosenberg=20 > Cc: simple=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > I'd like to agree with you too, unfortunately it's a CPIM requireme= nt=20 > as 2xx are successful responses. The SIMPLE charter requires CPIM= =20 > complience.=20 > James=20 > -----Original Message-----=20 > From: simple-admin@mailman.dynamicsoft.com=20 > [ mailto:simple-admin@mailman.dynamicsoft.com =20 > ]On Behalf Of Ngo, Da= i (c)=20 > Sent: 05 October 2001 17:52=20 > To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenber= g=20 > Cc: simple@mailman.dynamicsoft.com=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > I agree that there is no need to send an immediate, empty NOTIFY af= ter=20 > a 202 was sent in the pending case.=20 > -- Dai=20 > -----Original Message-----=20 > From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com =20 > ]=20 > Sent: Friday, October 05, 2001 10:33 AM=20 > To: 'ext Paul Kyzivat'; Jonathan Rosenberg=20 > Cc: simple@mailman.dynamicsoft.com=20 > Subject: RE: [Simple] 200 vs. 202=20 > My comments are in line.=20 > > -----Original Message-----=20 > > From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com =20 > ]=20 > > Sent: Friday, October 05, 2001 8:04 AM=20 > > To: Jonathan Rosenberg=20 > > Cc: Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com=20 > > Subject: Re: [Simple] 200 vs. 202=20 > >=20 > >=20 > Seems you are both saying the same thing. I seem to recall an earli= er=20 > dialogue where it was stated that non-Invite requests are treated= =20 > differently than Invites in that only one response in sent back to = the=20 > "Subscriber" in this case. So it would appear that the PA (with pr= oxy=20 > capabilities) will wait some predetermined amount of time to collec= t=20 > all of the responses (or until all are received whichever comes fir= st)=20 > and send back the best response. If the best is a 202, then does th= e=20 > proxy wait for the Notify and send the 202+Notify or just the 202 a= nd=20 > the Notify later? I guess I don't see the need for a 202 indicating= =20 > pending followed immediately by another message (Notify with no rea= l=20 > status) which adds no value.=20 >=20 >=20 >=20 > _______________________________________________=20 > simple mailing list=20 > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinfo/simple =20 > =20 >=20 --Boundary_(ID_/NWvrnzbd7ZskUDr8oS+Cg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

While reviewing the draft = "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in = existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is = maintained."

It seems to me that the above = statement contradicts with what we are saying here, that an empty notification is = needed to complete the three-ways handshake.

 

=

How do we reconcile this = conflict?

 

=

-- = Dai

 

=

 

=

 

=

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, October = 09, 2001 2:27 PM
To: Ngo, Dai (c); = 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul = Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] = 200 vs. 202

 

Maybe the confusion that we're having is centered around how to deal with = an
empty NOTIFY. If you = think of an empty NOTIFY as signifying nothing about the
status of the = subscription (pending or accepted) and nothing about the state
of the resource the = subscription is made to (in this case the presence agent),
then things get a lot = simpler.

If you think about it that way, then the processing of an empty NOTIFY = creates
a three-way handshake = to the subscription request, and that helps with forking
issues. =

If the events draft is updated to clarify this thinking (assuming that this is =
the behaviour desired), = and the presence draft is updated such that an *empty*
NOTIFY, and not one = with bogus information in it, is sent after a 202, then I
think things will get a = lot less fuzzy.

Jonathan? Adam?

Brian

-----Original Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]=
Sent: Tuesday, October = 09, 2001 8:32 AM
To: 'Brazier Lachlan'; = Stucker, Brian [NGB:B621:EXCH]; Moran Tim
(NET/Dallas); = adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan
Rosenberg =
Cc: = simple
Subject: RE: [Simple] = 200 vs. 202

 

In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-00.txt
from Adam Roach, it = states, "When a SUBSCRIBE request is successfully
processed or a relevant = change in the subscribed state occurs, the notifier
will construct and send = a NOTIFY request to the subscribers, as specified in
the contact field of = the SUBSCRIBE request. Such a message should be sent in
as timely a manner as = is practical".

In section 5.8 "Notifier Generation of NOTIFY Requests" = of
draft-ietf-simple-presence-03.txt it states, "If a subscription is accepted
(or politely blocked) a = NOTIFY must be sent after the 200 OK response to the
SUBSCRIBE has been = sent. Notifications MAY be sent at later times, possibly
when the presence state = of the presentity changes."

It makes more sense to NOT sending the empty NOTIFY after a 202. =

Regards,

-- Dai Ngo

-----Original Message-----
From: Brazier Lachlan = [mailto:lachlan.brazier@siemen= s.at]
Sent: Tuesday, October = 09, 2001 3:29 AM
To: 'Brian Stucker'; = Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo,
Dai (c); 'ext Paul = Kyzivat'; Jonathan Rosenberg
Cc: = simple
Subject: AW: [Simple] = 200 vs. 202

Hello,
  =
When a subscriber = receives a 200 on a SUBSCRIBE request, a NOTIFY from the
presentity can be = handled. NOTIFY's from other senders will be responded to
with an error (481). = The tags in the FROM header of these NOTIFY's are
different than the tag = in the To header in the response to the SUBSCRIBE.
  =
When a subscriber = receives a 202 on a SUBSCRIBE request, a NOTIFY from the
presentity can be = handled. NOTIFY's from other senders will be responded to
with an error (481). = The tags in the FROM header of these NOTIFY's are
different than the tag = in the To header in the response to the SUBSCRIBE.
  =
  =
The question is now, = when is the presentity sending the NOTIFY?
  =
If a 200 Ok was = returned to the SUBSCRIBE request, the PA of the presentity
knows the status of the = presentity. If a 202 Accepted was returned, it
doesn't know right now, = but it can find out.
  =
I believe that a NOTIFY = must be sent "immediately" after sending a 2xx
response to the = subscriber. What does "immediately mean"? Does it mean
sending the NOTIFY = without delay, or does it mean sending the NOTIFY when
the status is obtained = by the PA?
  =
If = "immediately" means after obtaining the status, I don't see the problem.
  =
If = "immediately" means without delay, the first NOTIFY after sending a 202
will be useless. I've = looked in the presence draft
(draft-ietf-simple-presence-03.txt), but I haven't found the phrase stating,
that a NOTIFY MUST be = sent immediately after sending a 202 Acepted. I only
found it for 200 = Ok.
Still, as 202 Accepted = is a positive response, the NOTIFY could be required. =

This leads to my next question: Why is it required?
Anyway, to follow the = requirements, I always can send an empty NOTIFY.
  =
  =
Please correct me, when = I stated something wrong or missunderstood
something!
  =
Lachlan =
  =
  =

-----Urspr=FCngliche Nachricht-----
Von: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Gesendet am: Dienstag, = 09. Oktober 2001 01:34
An: Moran Tim = (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext
Paul Kyzivat'; Jonathan = Rosenberg
Cc: = simple
Betreff: RE: [Simple] = 200 vs. 202

 

It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, = the
watcher must reject the = subsequent NOTIFY because it never saw what the TO
tag was from the = response to the SUBSCRIBE (because it was in the 200 OK).
You could argue that = the watcher takes the TO tag in the first response or
NOTIFY it gets back (as = long as the FROM tag and everything else matches
ok). However, that = seems to be a bit dangerous if we consider cases where
multiple packets are = being dropped (unintentionally or otherwise).

Forking subscriptions seems to be problematic at best unless you ACK = the
response (as Adam = pointed out with the 3-way handshake mention) like an
INVITE does instead of = relying on a NOTIFY that does nothing because CPIM
wants it. It's coming = from the wrong endpoint, as you say. I would think
that anything that = forks, and creates a meta-session routing requirement
needs to be = ACK'd.

Brian Stucker

 

-----Original Message-----
From: Moran Tim = (NET/Dallas) [ mailto:Tim.Moran@nokia.com
<mailto:Tim.Moran@nokia.com> = ]
Sent: Monday, October = 08, 2001 6:17 PM
To: adam.roach; = Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c);
'ext Paul Kyzivat'; = Jonathan Rosenberg
Cc: simple =
Subject: RE: [Simple] = 200 vs. 202

 

Three-way handshake in my dictionary implies A->B, A<-B, and then a = A->B
again. This is not the = case in a Subscribe, 200/202 and then a Notify in
the same direction as = the 2xx.. I am also puzzled by your "immediate"
requirement after a 202 = since your own draft uses phrases like ...

A 202 response indicates that there may be a sizable delay before = a
notification is = received, pending the actual creation of the subscription

If the notifier owner is interactively queried to determine whether = a
subscription is = allowed, a "202 Accept" response is returned immediately,
and the subsequent = NOTIFY request is suppressed until the notifier  owner
responds. =

Does the requirement for an immediate notify after a 202 only apply = to
forked requests? How = does the server know when a request has been forked? =

So let's say a Subscribe is forked and all the PAs respond with 202. = The
best one is returned to = the watcher and the rest dropped. All of the PAs
must also respond with = a Notify with useless information which the proxy
passes on. How = enlightened is the watcher upon receiving the dummy
Notifications? What = change is there in the state machine? Then there is the
scenario of 202s come = back, proxy timer expires so the best 202 is sent back
to watcher - and then a = 200 comes. I presume it would be dropped. The PA
which sent the 200 = sends a Notify (immediately) which is forwarded but there
is no preceding 200 so = the watcher drops it?  There is the out-of-sequence
clause, but if the 200 = never appears wouldn't the notify be rejected? Nodes
which know they can't = authorize at the time of subscription may respond
quicker than the node = which is actually doing the work of obtaining
authorization. Sounds = like some guidelines are needed as to how fast is
immediate and how long = a proxy waits for that 200 with the immediate notify. =

Tim M.



> -----Original Message-----
> From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com
<mailto:adam.roach@ericsson.com> ]
> Sent: Monday, = October 08, 2001 2:12 PM
> To: 'Brian = Stucker'; James Undery; Ngo, Dai (c); Moran Tim
> (NET/Dallas); =
> 'ext Paul = Kyzivat'; Jonathan Rosenberg
> Cc: simple =
> Subject: RE: = [Simple] 200 vs. 202
>
>
> Sorry; I haven't = been following this closely (things have been
> hellishly busy = recently). This conversation, though, seems to
> have taken a = dangerous turn.
>
> Remember that the = behaviour of SUB/NOT is general, and not just
> related to = presence. And, in the general case, forking of SUBSCRIBEs
> can be extremely = useful.
>
> However, without a = three-way handshake, such forking becomes quite
> messy and = unpleasant to implement.
>
> The immediate = NOTIFY is the third message of this three-way handshake.
> It can't be = removed from the base SUB/NOT draft; by extension, the use
> of SUB/NOT for = presence needs to keep it.
>
> /a =
>
>
> -----Original = Message-----
> From: Brian = Stucker [ mailto:bstucker@nortelnetwor= ks.com
<mailto:bstucker@nortelnetwor= ks.com> ]
> Sent: Monday, = October 08, 2001 1:54 PM
> To: James Undery; = Ngo, Dai (c); 'Moran Tim (NET/Dallas)';
> 'ext Paul = Kyzivat';
> Jonathan Rosenberg =
> Cc: simple =
> Subject: RE: = [Simple] 200 vs. 202
>
>
> Ok, as a = compromise, since we all seem to feel that the
> NOTIFY after a 202 = is
> totally useless... =
> Can't we make the = 202 act as an implied 'Offline' (or some
> other harmless, = and
> meaningless = indication)
> NOTIFY within the = context of how CPIM requirements work in a
> SIP network? =
> Gateway functions = to other
> protocols can = generate whatever messages they want from this,
> but in the =
> context of what = gets sent
> around in a SIP = network, the 202 acts as a NOTIFY itself.
> Heck, you could = even put dummy XML in the 202 message body if
> you really wanted =
> (but I'd rather = not).
> Brian Stucker =
> -----Original = Message-----
> From: James Undery = [ mailto:jundery@ubiquity.net
<mailto:jundery@ubiquity.net>= ]
> Sent: Monday, = October 08, 2001 5:12 AM
> To: Ngo, Dai (c); = 'Moran Tim (NET/Dallas)'; 'ext Paul
> Kyzivat'; Jonathan =
> Rosenberg =
> Cc: simple =
> Subject: RE: = [Simple] 200 vs. 202
>
>
> I'd like to agree = with you too, unfortunately it's a CPIM requirement
> as 2xx are = successful responses. The SIMPLE charter requires CPIM
> complience. =
> James =
> -----Original = Message-----
> From: simple-admin@mailman.dynamicsoft.com
> [ mailto:simple-admin= @mailman.dynamicsoft.com
<mailto:simple-admin= @mailman.dynamicsoft.com> ]On Behalf Of Ngo, Dai (c)
> Sent: 05 October = 2001 17:52
> To: 'Moran Tim = (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: = [Simple] 200 vs. 202
>
>
> I agree that there = is no need to send an immediate, empty NOTIFY after
> a 202 was sent in = the pending case.
> -- Dai =
> -----Original = Message-----
> From: Moran Tim = (NET/Dallas) [ mailto:Tim.Moran@nokia.com
<mailto:Tim.Moran@nokia.com> = ]
> Sent: Friday, = October 05, 2001 10:33 AM
> To: 'ext Paul = Kyzivat'; Jonathan Rosenberg
> Cc: simple@mailman.dynamicsoft.com
> Subject: RE: = [Simple] 200 vs. 202
> My comments are in = line.
> > -----Original Message-----
> > From: ext = Paul Kyzivat [ mailto:pkyzivat@cisco.com<= /font>
<mailto:pkyzivat@cisco.com> ] =
> > Sent: Friday, = October 05, 2001 8:04 AM
> > To: Jonathan = Rosenberg
> > Cc: Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com
> > Subject: Re: = [Simple] 200 vs. 202
> > =
> > =
> Seems you are both = saying the same thing. I seem to recall an earlier
> dialogue where it = was stated that non-Invite requests are treated
> differently than = Invites in that only one response in sent back to the
> = "Subscriber" in this case.  So it would appear that the PA (with proxy =
> capabilities) will = wait some predetermined amount of time to collect
> all of the = responses (or until all are received whichever comes first)
> and send back the = best response. If the best is a 202, then does the
> proxy wait for the = Notify and send the 202+Notify or just the 202 and
> the Notify later? = I guess I don't see the need for a 202 indicating
> pending followed = immediately by another message (Notify with no real
> status) which adds = no value.
>
>
>
> _______________________________________________
> simple mailing = list
> = simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=
<http://mailman.dynamicsoft.com/mailman/listinfo/simple= > 
> =

--Boundary_(ID_/NWvrnzbd7ZskUDr8oS+Cg)-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 13:36:22 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26884 for ; Thu, 1 Nov 2001 13:36:20 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1IWdb7028359; Thu, 1 Nov 2001 13:32:39 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17291; Thu, 1 Nov 2001 13:34:05 -0500 (EST) 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 LAA16936 for ; Thu, 1 Nov 2001 11:50:20 -0500 (EST) 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 KAA24591 for ; Thu, 1 Nov 2001 10:50:01 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 1 Nov 2001 10:43:07 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 10:49:11 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EA70653@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Ngo, Dai (c)" , "'Brazier Lachlan'" , "Moran Tim (NET/Dallas)" , "adam.roach" , James Undery , "'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_01C162F5.2407E010" 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: Thu, 1 Nov 2001 10:49:15 -0600 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_01C162F5.2407E010 Content-Type: text/plain; charset="iso-8859-1" The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. Thoughts? Regards, Brian Stucker -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, November 01, 2001 10:27 AM To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. How do we reconcile this conflict? -- Dai -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, October 09, 2001 2:27 PM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 Maybe the confusion that we're having is centered around how to deal with an empty NOTIFY. If you think of an empty NOTIFY as signifying nothing about the status of the subscription (pending or accepted) and nothing about the state of the resource the subscription is made to (in this case the presence agent), then things get a lot simpler. If you think about it that way, then the processing of an empty NOTIFY creates a three-way handshake to the subscription request, and that helps with forking issues. If the events draft is updated to clarify this thinking (assuming that this is the behaviour desired), and the presence draft is updated such that an *empty* NOTIFY, and not one with bogus information in it, is sent after a 202, then I think things will get a lot less fuzzy. Jonathan? Adam? Brian -----Original Message----- From: Ngo, Dai (c) [ mailto:c-Dai.Ngo@WCOM.Com ] Sent: Tuesday, October 09, 2001 8:32 AM To: 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-00.txt from Adam Roach, it states, "When a SUBSCRIBE request is successfully processed or a relevant change in the subscribed state occurs, the notifier will construct and send a NOTIFY request to the subscribers, as specified in the contact field of the SUBSCRIBE request. Such a message should be sent in as timely a manner as is practical". In section 5.8 "Notifier Generation of NOTIFY Requests" of draft-ietf-simple-presence-03.txt it states, "If a subscription is accepted (or politely blocked) a NOTIFY must be sent after the 200 OK response to the SUBSCRIBE has been sent. Notifications MAY be sent at later times, possibly when the presence state of the presentity changes." It makes more sense to NOT sending the empty NOTIFY after a 202. Regards, -- Dai Ngo -----Original Message----- From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ] Sent: Tuesday, October 09, 2001 3:29 AM To: 'Brian Stucker'; Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: AW: [Simple] 200 vs. 202 Hello, When a subscriber receives a 200 on a SUBSCRIBE request, a NOTIFY from the presentity can be handled. NOTIFY's from other senders will be responded to with an error (481). The tags in the FROM header of these NOTIFY's are different than the tag in the To header in the response to the SUBSCRIBE. When a subscriber receives a 202 on a SUBSCRIBE request, a NOTIFY from the presentity can be handled. NOTIFY's from other senders will be responded to with an error (481). The tags in the FROM header of these NOTIFY's are different than the tag in the To header in the response to the SUBSCRIBE. The question is now, when is the presentity sending the NOTIFY? If a 200 Ok was returned to the SUBSCRIBE request, the PA of the presentity knows the status of the presentity. If a 202 Accepted was returned, it doesn't know right now, but it can find out. I believe that a NOTIFY must be sent "immediately" after sending a 2xx response to the subscriber. What does "immediately mean"? Does it mean sending the NOTIFY without delay, or does it mean sending the NOTIFY when the status is obtained by the PA? If "immediately" means after obtaining the status, I don't see the problem. If "immediately" means without delay, the first NOTIFY after sending a 202 will be useless. I've looked in the presence draft (draft-ietf-simple-presence-03.txt), but I haven't found the phrase stating, that a NOTIFY MUST be sent immediately after sending a 202 Acepted. I only found it for 200 Ok. Still, as 202 Accepted is a positive response, the NOTIFY could be required. This leads to my next question: Why is it required? Anyway, to follow the requirements, I always can send an empty NOTIFY. Please correct me, when I stated something wrong or missunderstood something! Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] Gesendet am: Dienstag, 09. Oktober 2001 01:34 An: Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Betreff: RE: [Simple] 200 vs. 202 It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, the watcher must reject the subsequent NOTIFY because it never saw what the TO tag was from the response to the SUBSCRIBE (because it was in the 200 OK). You could argue that the watcher takes the TO tag in the first response or NOTIFY it gets back (as long as the FROM tag and everything else matches ok). However, that seems to be a bit dangerous if we consider cases where multiple packets are being dropped (unintentionally or otherwise). Forking subscriptions seems to be problematic at best unless you ACK the response (as Adam pointed out with the 3-way handshake mention) like an INVITE does instead of relying on a NOTIFY that does nothing because CPIM wants it. It's coming from the wrong endpoint, as you say. I would think that anything that forks, and creates a meta-session routing requirement needs to be ACK'd. Brian Stucker -----Original Message----- From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com < mailto:Tim.Moran@nokia.com > ] Sent: Monday, October 08, 2001 6:17 PM To: adam.roach; Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 Three-way handshake in my dictionary implies A->B, A<-B, and then a A->B again. This is not the case in a Subscribe, 200/202 and then a Notify in the same direction as the 2xx.. I am also puzzled by your "immediate" requirement after a 202 since your own draft uses phrases like ... A 202 response indicates that there may be a sizable delay before a notification is received, pending the actual creation of the subscription If the notifier owner is interactively queried to determine whether a subscription is allowed, a "202 Accept" response is returned immediately, and the subsequent NOTIFY request is suppressed until the notifier owner responds. Does the requirement for an immediate notify after a 202 only apply to forked requests? How does the server know when a request has been forked? So let's say a Subscribe is forked and all the PAs respond with 202. The best one is returned to the watcher and the rest dropped. All of the PAs must also respond with a Notify with useless information which the proxy passes on. How enlightened is the watcher upon receiving the dummy Notifications? What change is there in the state machine? Then there is the scenario of 202s come back, proxy timer expires so the best 202 is sent back to watcher - and then a 200 comes. I presume it would be dropped. The PA which sent the 200 sends a Notify (immediately) which is forwarded but there is no preceding 200 so the watcher drops it? There is the out-of-sequence clause, but if the 200 never appears wouldn't the notify be rejected? Nodes which know they can't authorize at the time of subscription may respond quicker than the node which is actually doing the work of obtaining authorization. Sounds like some guidelines are needed as to how fast is immediate and how long a proxy waits for that 200 with the immediate notify. Tim M. > -----Original Message----- > From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com < mailto:adam.roach@ericsson.com > ] > Sent: Monday, October 08, 2001 2:12 PM > To: 'Brian Stucker'; James Undery; Ngo, Dai (c); Moran Tim > (NET/Dallas); > 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > Sorry; I haven't been following this closely (things have been > hellishly busy recently). This conversation, though, seems to > have taken a dangerous turn. > > Remember that the behaviour of SUB/NOT is general, and not just > related to presence. And, in the general case, forking of SUBSCRIBEs > can be extremely useful. > > However, without a three-way handshake, such forking becomes quite > messy and unpleasant to implement. > > The immediate NOTIFY is the third message of this three-way handshake. > It can't be removed from the base SUB/NOT draft; by extension, the use > of SUB/NOT for presence needs to keep it. > > /a > > > -----Original Message----- > From: Brian Stucker [ mailto:bstucker@nortelnetworks.com < mailto:bstucker@nortelnetworks.com > ] > Sent: Monday, October 08, 2001 1:54 PM > To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; > 'ext Paul Kyzivat'; > Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > Ok, as a compromise, since we all seem to feel that the > NOTIFY after a 202 is > totally useless... > Can't we make the 202 act as an implied 'Offline' (or some > other harmless, and > meaningless indication) > NOTIFY within the context of how CPIM requirements work in a > SIP network? > Gateway functions to other > protocols can generate whatever messages they want from this, > but in the > context of what gets sent > around in a SIP network, the 202 acts as a NOTIFY itself. > Heck, you could even put dummy XML in the 202 message body if > you really wanted > (but I'd rather not). > Brian Stucker > -----Original Message----- > From: James Undery [ mailto:jundery@ubiquity.net < mailto:jundery@ubiquity.net > ] > Sent: Monday, October 08, 2001 5:12 AM > To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul > Kyzivat'; Jonathan > Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > I'd like to agree with you too, unfortunately it's a CPIM requirement > as 2xx are successful responses. The SIMPLE charter requires CPIM > complience. > James > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [ mailto:simple-admin@mailman.dynamicsoft.com < mailto:simple-admin@mailman.dynamicsoft.com > ]On Behalf Of Ngo, Dai (c) > Sent: 05 October 2001 17:52 > To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 200 vs. 202 > > > I agree that there is no need to send an immediate, empty NOTIFY after > a 202 was sent in the pending case. > -- Dai > -----Original Message----- > From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com < mailto:Tim.Moran@nokia.com > ] > Sent: Friday, October 05, 2001 10:33 AM > To: 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 200 vs. 202 > My comments are in line. > > -----Original Message----- > > From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com < mailto:pkyzivat@cisco.com > ] > > Sent: Friday, October 05, 2001 8:04 AM > > To: Jonathan Rosenberg > > Cc: Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] 200 vs. 202 > > > > > Seems you are both saying the same thing. I seem to recall an earlier > dialogue where it was stated that non-Invite requests are treated > differently than Invites in that only one response in sent back to the > "Subscriber" in this case. So it would appear that the PA (with proxy > capabilities) will wait some predetermined amount of time to collect > all of the responses (or until all are received whichever comes first) > and send back the best response. If the best is a 202, then does the > proxy wait for the Notify and send the 202+Notify or just the 202 and > the Notify later? I guess I don't see the need for a 202 indicating > pending followed immediately by another message (Notify with no real > status) which adds no value. > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple < http://mailman.dynamicsoft.com/mailman/listinfo/simple > > ------_=_NextPart_001_01C162F5.2407E010 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202
The=20 wording there can be taken several ways, and probably needs to be = clarified. We=20 really need to be talking about two notifications at the point at which = a=20 pending subscription comes in: notifying the client that has a=20 event-package.winfo subscription, and notifying the client that is = requesting=20 the new event-package subscription (where in this case, event-package = is likely=20 to be "presence").
 
I=20 would argue that you should send an empty NOTIFY to the "presence" = subscription,=20 and send a NOTIFY to the "presence.winfo" subscriber telling them that = the=20 subscription is waiting for their authorization. If the subscription is = a=20 refresh of the pending "presence" subscription, then you need to send = an empty=20 NOTIFY to the "presence" subscription, but it's a MAY = notify on the=20 "presence.winfo" side (the renotification may not be particularly=20 useful).
 
 
I=20 think the new version of the events draft is supposed to be sent out = today, so=20 maybe that'll provide more clarification.
 
Thoughts?
 
Regards,
 
Brian=20 Stucker
-----Original Message-----
From: Ngo, Dai (c)=20 [mailto:c-Dai.Ngo@WCOM.Com]
Sent: Thursday, November 01, = 2001 10:27=20 AM
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; = Moran Tim=20 (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

While = reviewing the=20 draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 = "The=20 Watcherinfo State Machine" it says, "If, when a subscription arrives, = there is=20 no authorization policy in existence, the subscription moves into the = pending=20 state. In this state, the server is awaiting an authorization = decision.=20 *No notifications are=20 generated*, but the subscription FSM is=20 maintained."

It seems = to me that=20 the above statement contradicts with what we are saying here, that an = empty=20 notification is needed to complete the three-ways=20 handshake.

 

How do we = reconcile=20 this conflict?

 

--=20 Dai

 

 

 

-----Original=20 Message-----
From: = Brian=20 Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, October 09, = 2001 2:27=20 PM
To: Ngo, Dai = (c); 'Brazier=20 Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul = Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs.=20 202

 

Maybe the=20 confusion that we're having is centered around how to deal with=20 an
empty NOTIFY.=20 If you think of an empty NOTIFY as signifying nothing about = the=20
status of the = subscription=20 (pending or accepted) and nothing about the state =
of the resource the = subscription is made=20 to (in this case the presence agent),
then things get a lot = simpler.=20

If you=20 think about it that way, then the processing of an empty NOTIFY=20 creates
a=20 three-way handshake to the subscription request, and that helps with=20 forking
issues.

If the=20 events draft is updated to clarify this thinking (assuming that this = is=20
the = behaviour=20 desired), and the presence draft is updated such that an = *empty*=20
NOTIFY, and not = one with bogus=20 information in it, is sent after a 202, then I =
think things will get a lot = less=20 fuzzy.

Jonathan?=20 Adam?

Brian

-----Original Message----- =
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]= =20
Sent: Tuesday, = October 09, 2001=20 8:32 AM
To:=20 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran = Tim=20
(NET/Dallas); = adam.roach; James=20 Undery; 'ext Paul Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. 202=20

 

In=20 section 5.2.3 "Notifier NOTIFY Behavior" of=20 draft-ietf-sip-events-00.txt
from Adam Roach, it states, "When a = SUBSCRIBE request=20 is successfully
processed or a relevant change in the = subscribed state=20 occurs, the notifier
will construct and send a NOTIFY request to = the=20 subscribers, as specified in
the contact field of the SUBSCRIBE request. = Such a=20 message should be sent in
as timely a manner as is = practical".=20

In=20 section 5.8 "Notifier Generation of NOTIFY Requests" of =
draft-ietf-simple-presence-03.txt it = states, "If a=20 subscription is accepted
(or politely blocked) a NOTIFY must be sent = after the=20 200 OK response to the
SUBSCRIBE has been sent. Notifications MAY = be sent at=20 later times, possibly
when the presence state of the presentity=20 changes."

It makes=20 more sense to NOT sending the empty NOTIFY after a 202. =

Regards,

-- Dai=20 Ngo

-----Original Message----- =
From: Brazier Lachlan [mailto:lachlan.brazier@siemen= s.at]=20
Sent: Tuesday,=20 October 09, 2001 3:29 AM
To: 'Brian Stucker'; Moran Tim = (NET/Dallas);=20 adam.roach; James Undery; Ngo,
Dai (c); 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc:=20 simple
Subject:=20 AW: [Simple] 200 vs. 202

Hello,
 
When a subscriber receives a 200 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's from = other senders=20 will be responded to
with an error (481). The tags in the FROM = header of=20 these NOTIFY's are
different than the tag in the To header in = the=20 response to the SUBSCRIBE.
 
When a subscriber receives a 202 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's from = other senders=20 will be responded to
with an error (481). The tags in the FROM = header of=20 these NOTIFY's are
different than the tag in the To header in = the=20 response to the SUBSCRIBE.
 
 
The question is now, when is the presentity = sending=20 the NOTIFY?
 
If a 200 Ok was returned to the SUBSCRIBE = request, the=20 PA of the presentity
knows the status of the presentity. If a = 202 Accepted=20 was returned, it
doesn't know right now, but it can find=20 out.
 
I believe that a NOTIFY must be sent = "immediately"=20 after sending a 2xx
response to the subscriber. What does = "immediately=20 mean"? Does it mean
sending the NOTIFY without delay, or does = it mean=20 sending the NOTIFY when
the status is obtained by the = PA?=20
 
If "immediately" means after = obtaining=20 the status, I don't see the problem.
 
If "immediately" means without delay, the = first NOTIFY=20 after sending a 202
will be useless. I've looked in the = presence=20 draft
(draft-ietf-simple-presence-03.txt), but I = haven't=20 found the phrase stating,
that a NOTIFY MUST be sent immediately = after sending a=20 202 Acepted. I only
found it for 200 Ok. =
Still, as 202 Accepted is a = positive=20 response, the NOTIFY could be required.

This=20 leads to my next question: Why is it required? =
Anyway, to follow the = requirements, I=20 always can send an empty NOTIFY.
 
 
Please correct me, when I stated something = wrong or=20 missunderstood
something!
 
Lachlan
 
 

-----Urspr=FCngliche = Nachricht-----=20
Von: Brian Stucker = [mailto:bstucker@nortelnetwor= ks.com]=20
Gesendet am: = Dienstag, 09.=20 Oktober 2001 01:34
An: Moran Tim (NET/Dallas); adam.roach; = James Undery;=20 Ngo, Dai (c); 'ext
Paul Kyzivat'; Jonathan = Rosenberg=20
Cc: = simple=20
Betreff: RE: = [Simple] 200 vs.=20 202

 

It is my=20 understanding that if the 200 OK is dropped to a SUBSCRIBE, = the=20
watcher must = reject the=20 subsequent NOTIFY because it never saw what the TO =
tag was from the response to = the=20 SUBSCRIBE (because it was in the 200 OK).
You could argue that the watcher takes the = TO tag in=20 the first response or
NOTIFY it gets back (as long as the FROM = tag and=20 everything else matches
ok). However, that seems to be a bit = dangerous if we=20 consider cases where
multiple packets are being dropped = (unintentionally or=20 otherwise).

Forking=20 subscriptions seems to be problematic at best unless you ACK = the=20
response (as Adam = pointed out=20 with the 3-way handshake mention) like an
INVITE does instead of relying on a NOTIFY = that does=20 nothing because CPIM
wants it. It's coming from the wrong = endpoint, as you=20 say. I would think
that anything that forks, and creates a = meta-session=20 routing requirement
needs to be ACK'd. =

Brian=20 Stucker

 

-----Original Message----- =
From: Moran Tim (NET/Dallas) = [ mailto:Tim.Moran@nokia.com=20
<mailto:Tim.Moran@nokia.com> = ]=20
Sent: Monday,=20 October 08, 2001 6:17 PM
To: adam.roach; Stucker, Brian = [NGB:B621:EXCH]; James=20 Undery; Ngo, Dai (c);
'ext Paul Kyzivat'; Jonathan Rosenberg=20
Cc: = simple=20
Subject: RE:=20 [Simple] 200 vs. 202

 

Three-way=20 handshake in my dictionary implies A->B, A<-B, and then a=20 A->B
again.=20 This is not the case in a Subscribe, 200/202 and then a Notify=20 in
the same=20 direction as the 2xx.. I am also puzzled by your = "immediate"=20
requirement after = a 202 since=20 your own draft uses phrases like ...

A 202=20 response indicates that there may be a sizable delay before = a=20
notification is = received,=20 pending the actual creation of the subscription =

If the=20 notifier owner is interactively queried to determine whether = a=20
subscription is = allowed, a "202=20 Accept" response is returned immediately,
and the subsequent NOTIFY request is = suppressed until=20 the notifier  owner
responds.

Does the=20 requirement for an immediate notify after a 202 only apply = to=20
forked requests? = How does the=20 server know when a request has been forked? =

So let's=20 say a Subscribe is forked and all the PAs respond with 202. = The=20
best one is = returned to the=20 watcher and the rest dropped. All of the PAs
must also respond with a = Notify with=20 useless information which the proxy
passes on. How enlightened is the watcher = upon=20 receiving the dummy
Notifications? What change is there in the = state=20 machine? Then there is the
scenario of 202s come back, proxy timer = expires so the=20 best 202 is sent back
to watcher - and then a 200 comes. I = presume it would=20 be dropped. The PA
which sent the 200 sends a Notify = (immediately) which=20 is forwarded but there
is no preceding 200 so the watcher drops = it? =20 There is the out-of-sequence
clause, but if the 200 never appears = wouldn't the=20 notify be rejected? Nodes
which know they can't authorize at the time = of=20 subscription may respond
quicker than the node which is actually = doing the work=20 of obtaining
authorization. Sounds like some guidelines = are needed=20 as to how fast is
immediate and how long a proxy waits for = that 200 with=20 the immediate notify.

Tim M.=20

>=20 -----Original Message-----
> From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com=20
<mailto:adam.roach@ericsson.com> ]=20
> = Sent:=20 Monday, October 08, 2001 2:12 PM
> To: 'Brian Stucker'; James Undery; = Ngo, Dai (c);=20 Moran Tim
>=20 (NET/Dallas);
> 'ext Paul Kyzivat'; Jonathan Rosenberg =
> = Cc: simple=20
> = Subject: RE:=20 [Simple] 200 vs. 202
>
>
> Sorry; I haven't been following this = closely=20 (things have been
> hellishly busy recently). This = conversation,=20 though, seems to
> have taken a dangerous turn.=20
> =
> = Remember=20 that the behaviour of SUB/NOT is general, and not just =
> related to presence. = And, in the=20 general case, forking of SUBSCRIBEs
> can be extremely useful. =
>
> However, without a three-way = handshake, such=20 forking becomes quite
> messy and unpleasant to implement.=20
> =
> = The=20 immediate NOTIFY is the third message of this three-way handshake.=20
> = It can't be=20 removed from the base SUB/NOT draft; by extension, the use=20
> = of SUB/NOT=20 for presence needs to keep it.
>
> /a
>
>
> -----Original Message-----=20
> = From: Brian=20 Stucker [ mailto:bstucker@nortelnetwor= ks.com=20
<mailto:bstucker@nortelnetwor= ks.com>=20 ]
> Sent:=20 Monday, October 08, 2001 1:54 PM
> To: James Undery; Ngo, Dai (c); 'Moran = Tim=20 (NET/Dallas)';
> 'ext Paul Kyzivat'; =
> Jonathan Rosenberg=20
> = Cc: simple=20
> = Subject: RE:=20 [Simple] 200 vs. 202
>
>
> Ok, as a compromise, since we all seem = to feel=20 that the
>=20 NOTIFY after a 202 is
> totally useless... =
> Can't we make the 202 = act as an=20 implied 'Offline' (or some
> other harmless, and =
> meaningless indication) =
> = NOTIFY=20 within the context of how CPIM requirements work in a =
> SIP network? =
> Gateway functions to = other=20
> = protocols=20 can generate whatever messages they want from this, =
> but in the =
> context of what gets = sent=20
> = around in a=20 SIP network, the 202 acts as a NOTIFY itself.
> Heck, you could even = put dummy XML=20 in the 202 message body if
> you really wanted =
> (but I'd rather not).=20
> = Brian=20 Stucker
>=20 -----Original Message-----
> From: James Undery [ mailto:jundery@ubiquity.net=20
<mailto:jundery@ubiquity.net>= ]=20
> = Sent:=20 Monday, October 08, 2001 5:12 AM
> To: Ngo, Dai (c); 'Moran Tim = (NET/Dallas)'; 'ext=20 Paul
>=20 Kyzivat'; Jonathan
> Rosenberg
> Cc: simple
> Subject: RE: [Simple] 200 vs. 202=20
> =
> =
> = I'd like to=20 agree with you too, unfortunately it's a CPIM requirement=20
> = as 2xx are=20 successful responses. The SIMPLE charter requires CPIM =
> complience. =
> James =
> -----Original = Message-----=20
> = From:=20 simple-admin@mailman.dynamicsoft.com
> [ mailto:simple-admin= @mailman.dynamicsoft.com=20
<mailto:simple-admin= @mailman.dynamicsoft.com>=20 ]On Behalf Of Ngo, Dai (c)
> Sent: 05 October 2001 17:52=20
> = To: 'Moran=20 Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg=20
> = Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
> =
> =
> = I agree that=20 there is no need to send an immediate, empty NOTIFY after=20
> = a 202 was=20 sent in the pending case.
> -- Dai
> -----Original Message-----=20
> = From: Moran=20 Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20
<mailto:Tim.Moran@nokia.com> = ]=20
> = Sent:=20 Friday, October 05, 2001 10:33 AM
> To: 'ext Paul Kyzivat'; Jonathan = Rosenberg=20
> = Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
> = My comments=20 are in line.
>=20 > -----Original Message-----
> > From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com<= /FONT>=20
<mailto:pkyzivat@cisco.com> = ]=20
> = > Sent:=20 Friday, October 05, 2001 8:04 AM
> > To: Jonathan Rosenberg=20
> = > Cc:=20 Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com =
> > Subject: Re: = [Simple] 200 vs.=20 202
> >=20
> = >=20
> = Seems you=20 are both saying the same thing. I seem to recall an earlier=20
> = dialogue=20 where it was stated that non-Invite requests are treated=20
> = differently=20 than Invites in that only one response in sent back to the=20
> = "Subscriber"=20 in this case.  So it would appear that the PA (with proxy=20
> = capabilities) will wait some predetermined amount of time to collect=20
> = all of the=20 responses (or until all are received whichever comes first)=20
> = and send=20 back the best response. If the best is a 202, then does the=20
> = proxy wait=20 for the Notify and send the 202+Notify or just the 202 and=20
> = the Notify=20 later? I guess I don't see the need for a 202 indicating=20
> = pending=20 followed immediately by another message (Notify with no real=20
> = status)=20 which adds no value.
>
>
>
> = _______________________________________________=20
> = simple=20 mailing list
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
<http://mailman.dynamicsoft.com/mailman/listinfo/simple> =20
> =

------_=_NextPart_001_01C162F5.2407E010-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 13:37:14 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26920 for ; Thu, 1 Nov 2001 13:37:12 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1IXJb7028374; Thu, 1 Nov 2001 13:33:19 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17309; Thu, 1 Nov 2001 13:34:51 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17100 for ; Thu, 1 Nov 2001 12:36:23 -0500 (EST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.americas.nokia.com [172.18.194.217]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA1HaID24052 for ; Thu, 1 Nov 2001 19:36:18 +0200 (EET) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA1HaYQ13250 for ; Thu, 1 Nov 2001 11:36:35 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 1 Nov 2001 11:35:54 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Nov 2001 11:35:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [Simple] 200 vs. 202 Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A421B@daebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C162FB.AA81F77C" Thread-Topic: [Simple] 200 vs. 202 Thread-Index: AcFi9UxAVAChSM7nEdWBTgBQi2X+DwAA2ZCA From: "Moran Tim (NET/Dallas)" To: "'ext Brian Stucker'" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , "James Undery" , "'ext Paul Kyzivat'" , "Jonathan Rosenberg" Cc: "simple" X-OriginalArrivalTime: 01 Nov 2001 17:35:58.0483 (UTC) FILETIME=[AACB0630:01C162FB] 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, 1 Nov 2001 11:35:58 -0600 This is a multi-part message in MIME format. ------_=_NextPart_001_01C162FB.AA81F77C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To me the term Pending (as in 202 Pending) says hold on I can not answer right now. Sorry, but I just don't see the justification in the immediate dummy message to the receiver of the 202. I understand (think I do) that the empty Notify request is sent so that the notifier can know that the 202 was received because it causes a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake.=20 =20 It would appear the assumption is that 3-way handshake is required. What is wrong with the subscriber timing out on receiving a response from the notifer (200 or 202) and resending the subscribe? That is, what is wrong with a two-way handshake with a timer? =20 Tim M. -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 10:49 AM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). =20 I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). =20 =20 I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. =20 Thoughts? =20 Regards, =20 Brian Stucker -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, November 01, 2001 10:27 AM To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. =20 How do we reconcile this conflict? =20 -- Dai =20 =20 =20 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com]=20 Sent: Tuesday, October 09, 2001 2:27 PM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 =20 Maybe the confusion that we're having is centered around how to deal with an=20 empty NOTIFY. If you think of an empty NOTIFY as signifying nothing about the=20 status of the subscription (pending or accepted) and nothing about the state=20 of the resource the subscription is made to (in this case the presence agent),=20 then things get a lot simpler.=20 If you think about it that way, then the processing of an empty NOTIFY creates=20 a three-way handshake to the subscription request, and that helps with forking=20 issues.=20 If the events draft is updated to clarify this thinking (assuming that this is=20 the behaviour desired), and the presence draft is updated such that an *empty*=20 NOTIFY, and not one with bogus information in it, is sent after a 202, then I=20 think things will get a lot less fuzzy.=20 Jonathan? Adam?=20 Brian=20 -----Original Message-----=20 From: Ngo, Dai (c) [ mailto:c-Dai.Ngo@WCOM.Com]=20 Sent: Tuesday, October 09, 2001 8:32 AM=20 To: 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran Tim=20 (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan=20 Rosenberg=20 Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 =20 In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-00.txt=20 from Adam Roach, it states, "When a SUBSCRIBE request is successfully=20 processed or a relevant change in the subscribed state occurs, the notifier=20 will construct and send a NOTIFY request to the subscribers, as specified in=20 the contact field of the SUBSCRIBE request. Such a message should be sent in=20 as timely a manner as is practical".=20 In section 5.8 "Notifier Generation of NOTIFY Requests" of=20 draft-ietf-simple-presence-03.txt it states, "If a subscription is accepted=20 (or politely blocked) a NOTIFY must be sent after the 200 OK response to the=20 SUBSCRIBE has been sent. Notifications MAY be sent at later times, possibly=20 when the presence state of the presentity changes."=20 It makes more sense to NOT sending the empty NOTIFY after a 202.=20 Regards,=20 -- Dai Ngo=20 -----Original Message-----=20 From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at]=20 Sent: Tuesday, October 09, 2001 3:29 AM=20 To: 'Brian Stucker'; Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo,=20 Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg=20 Cc: simple=20 Subject: AW: [Simple] 200 vs. 202=20 Hello,=20 =20 When a subscriber receives a 200 on a SUBSCRIBE request, a NOTIFY from the=20 presentity can be handled. NOTIFY's from other senders will be responded to=20 with an error (481). The tags in the FROM header of these NOTIFY's are=20 different than the tag in the To header in the response to the SUBSCRIBE.=20 =20 When a subscriber receives a 202 on a SUBSCRIBE request, a NOTIFY from the=20 presentity can be handled. NOTIFY's from other senders will be responded to=20 with an error (481). The tags in the FROM header of these NOTIFY's are=20 different than the tag in the To header in the response to the SUBSCRIBE.=20 =20 =20 The question is now, when is the presentity sending the NOTIFY?=20 =20 If a 200 Ok was returned to the SUBSCRIBE request, the PA of the presentity=20 knows the status of the presentity. If a 202 Accepted was returned, it=20 doesn't know right now, but it can find out.=20 =20 I believe that a NOTIFY must be sent "immediately" after sending a 2xx=20 response to the subscriber. What does "immediately mean"? Does it mean=20 sending the NOTIFY without delay, or does it mean sending the NOTIFY when=20 the status is obtained by the PA?=20 =20 If "immediately" means after obtaining the status, I don't see the problem.=20 =20 If "immediately" means without delay, the first NOTIFY after sending a 202=20 will be useless. I've looked in the presence draft=20 (draft-ietf-simple-presence-03.txt), but I haven't found the phrase stating,=20 that a NOTIFY MUST be sent immediately after sending a 202 Acepted. I only=20 found it for 200 Ok.=20 Still, as 202 Accepted is a positive response, the NOTIFY could be required.=20 This leads to my next question: Why is it required?=20 Anyway, to follow the requirements, I always can send an empty NOTIFY.=20 =20 =20 Please correct me, when I stated something wrong or missunderstood=20 something!=20 =20 Lachlan=20 =20 =20 -----Urspr=FCngliche Nachricht-----=20 Von: Brian Stucker [ mailto:bstucker@nortelnetworks.com]=20 Gesendet am: Dienstag, 09. Oktober 2001 01:34=20 An: Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg=20 Cc: simple=20 Betreff: RE: [Simple] 200 vs. 202=20 =20 It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, the watcher must reject the subsequent NOTIFY because it never saw what the TO=20 tag was from the response to the SUBSCRIBE (because it was in the 200 OK).=20 You could argue that the watcher takes the TO tag in the first response or=20 NOTIFY it gets back (as long as the FROM tag and everything else matches ok). However, that seems to be a bit dangerous if we consider cases where=20 multiple packets are being dropped (unintentionally or otherwise).=20 Forking subscriptions seems to be problematic at best unless you ACK the response (as Adam pointed out with the 3-way handshake mention) like an=20 INVITE does instead of relying on a NOTIFY that does nothing because CPIM=20 wants it. It's coming from the wrong endpoint, as you say. I would think that anything that forks, and creates a meta-session routing requirement needs to be ACK'd.=20 Brian Stucker=20 =20 -----Original Message-----=20 From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20 < mailto:Tim.Moran@nokia.com> ]=20 Sent: Monday, October 08, 2001 6:17 PM=20 To: adam.roach; Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c);=20 'ext Paul Kyzivat'; Jonathan Rosenberg=20 Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 =20 Three-way handshake in my dictionary implies A->B, A<-B, and then a A->B again. This is not the case in a Subscribe, 200/202 and then a Notify in the same direction as the 2xx.. I am also puzzled by your "immediate"=20 requirement after a 202 since your own draft uses phrases like ...=20 A 202 response indicates that there may be a sizable delay before a=20 notification is received, pending the actual creation of the subscription=20 If the notifier owner is interactively queried to determine whether a=20 subscription is allowed, a "202 Accept" response is returned immediately,=20 and the subsequent NOTIFY request is suppressed until the notifier owner=20 responds.=20 Does the requirement for an immediate notify after a 202 only apply to=20 forked requests? How does the server know when a request has been forked?=20 So let's say a Subscribe is forked and all the PAs respond with 202. The best one is returned to the watcher and the rest dropped. All of the PAs must also respond with a Notify with useless information which the proxy passes on. How enlightened is the watcher upon receiving the dummy=20 Notifications? What change is there in the state machine? Then there is the=20 scenario of 202s come back, proxy timer expires so the best 202 is sent back=20 to watcher - and then a 200 comes. I presume it would be dropped. The PA which sent the 200 sends a Notify (immediately) which is forwarded but there=20 is no preceding 200 so the watcher drops it? There is the out-of-sequence=20 clause, but if the 200 never appears wouldn't the notify be rejected? Nodes=20 which know they can't authorize at the time of subscription may respond=20 quicker than the node which is actually doing the work of obtaining=20 authorization. Sounds like some guidelines are needed as to how fast is=20 immediate and how long a proxy waits for that 200 with the immediate notify.=20 Tim M.=20 > -----Original Message-----=20 > From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com=20 < mailto:adam.roach@ericsson.com> ]=20 > Sent: Monday, October 08, 2001 2:12 PM=20 > To: 'Brian Stucker'; James Undery; Ngo, Dai (c); Moran Tim=20 > (NET/Dallas);=20 > 'ext Paul Kyzivat'; Jonathan Rosenberg=20 > Cc: simple=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > Sorry; I haven't been following this closely (things have been=20 > hellishly busy recently). This conversation, though, seems to=20 > have taken a dangerous turn.=20 >=20 > Remember that the behaviour of SUB/NOT is general, and not just=20 > related to presence. And, in the general case, forking of SUBSCRIBEs=20 > can be extremely useful.=20 >=20 > However, without a three-way handshake, such forking becomes quite=20 > messy and unpleasant to implement.=20 >=20 > The immediate NOTIFY is the third message of this three-way handshake. > It can't be removed from the base SUB/NOT draft; by extension, the use > of SUB/NOT for presence needs to keep it.=20 >=20 > /a=20 >=20 >=20 > -----Original Message-----=20 > From: Brian Stucker [ mailto:bstucker@nortelnetworks.com=20 < mailto:bstucker@nortelnetworks.com> ]=20 > Sent: Monday, October 08, 2001 1:54 PM=20 > To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)';=20 > 'ext Paul Kyzivat';=20 > Jonathan Rosenberg=20 > Cc: simple=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > Ok, as a compromise, since we all seem to feel that the=20 > NOTIFY after a 202 is=20 > totally useless...=20 > Can't we make the 202 act as an implied 'Offline' (or some=20 > other harmless, and=20 > meaningless indication)=20 > NOTIFY within the context of how CPIM requirements work in a=20 > SIP network?=20 > Gateway functions to other=20 > protocols can generate whatever messages they want from this,=20 > but in the=20 > context of what gets sent=20 > around in a SIP network, the 202 acts as a NOTIFY itself.=20 > Heck, you could even put dummy XML in the 202 message body if=20 > you really wanted=20 > (but I'd rather not).=20 > Brian Stucker=20 > -----Original Message-----=20 > From: James Undery [ mailto:jundery@ubiquity.net=20 < mailto:jundery@ubiquity.net> ]=20 > Sent: Monday, October 08, 2001 5:12 AM=20 > To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul=20 > Kyzivat'; Jonathan=20 > Rosenberg=20 > Cc: simple=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > I'd like to agree with you too, unfortunately it's a CPIM requirement=20 > as 2xx are successful responses. The SIMPLE charter requires CPIM=20 > complience.=20 > James=20 > -----Original Message-----=20 > From: simple-admin@mailman.dynamicsoft.com=20 > [ mailto:simple-admin@mailman.dynamicsoft.com=20 < mailto:simple-admin@mailman.dynamicsoft.com> ]On Behalf Of Ngo, Dai (c)=20 > Sent: 05 October 2001 17:52=20 > To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg=20 > Cc: simple@mailman.dynamicsoft.com=20 > Subject: RE: [Simple] 200 vs. 202=20 >=20 >=20 > I agree that there is no need to send an immediate, empty NOTIFY after > a 202 was sent in the pending case.=20 > -- Dai=20 > -----Original Message-----=20 > From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20 < mailto:Tim.Moran@nokia.com> ]=20 > Sent: Friday, October 05, 2001 10:33 AM=20 > To: 'ext Paul Kyzivat'; Jonathan Rosenberg=20 > Cc: simple@mailman.dynamicsoft.com=20 > Subject: RE: [Simple] 200 vs. 202=20 > My comments are in line.=20 > > -----Original Message-----=20 > > From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com=20 < mailto:pkyzivat@cisco.com> ]=20 > > Sent: Friday, October 05, 2001 8:04 AM=20 > > To: Jonathan Rosenberg=20 > > Cc: Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com=20 > > Subject: Re: [Simple] 200 vs. 202=20 > >=20 > >=20 > Seems you are both saying the same thing. I seem to recall an earlier=20 > dialogue where it was stated that non-Invite requests are treated=20 > differently than Invites in that only one response in sent back to the > "Subscriber" in this case. So it would appear that the PA (with proxy > capabilities) will wait some predetermined amount of time to collect=20 > all of the responses (or until all are received whichever comes first) > and send back the best response. If the best is a 202, then does the=20 > proxy wait for the Notify and send the 202+Notify or just the 202 and=20 > the Notify later? I guess I don't see the need for a 202 indicating=20 > pending followed immediately by another message (Notify with no real=20 > status) which adds no value.=20 >=20 >=20 >=20 > _______________________________________________=20 > simple mailing list=20 > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinfo/simple=20 < http://mailman.dynamicsoft.com/mailman/listinfo/simple> =20 >=20 ------_=_NextPart_001_01C162FB.AA81F77C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202
To me=20 the term Pending (as in 202 Pending) says hold on I can not answer = right=20 now. Sorry, but I just don't see the justification in the immediate = dummy=20 message to the receiver of the 202. I understand (think I do) that the = empty=20 Notify request is sent so that the notifier can know that the 202 was = received=20 because it causes a 200 from Subscriber to Notifier. 4 messages to do a = 3 way=20 handshake.
 
It=20 would appear the assumption is that 3-way handshake is required.=20 What is wrong with the subscriber timing out on receiving a = response from=20 the notifer (200 or 202) and resending the subscribe? That is, what is = wrong=20 with a  two-way handshake with a timer?
 
Tim=20 M.
-----Original Message-----
From: ext Brian Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, = November 01,=20 2001 10:49 AM
To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim = (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. = 202

The=20 wording there can be taken several ways, and probably needs to be = clarified.=20 We really need to be talking about two notifications at the point at = which a=20 pending subscription comes in: notifying the client that has a=20 event-package.winfo subscription, and notifying the client that is = requesting=20 the new event-package subscription (where in this case, event-package = is=20 likely to be "presence").
 
I=20 would argue that you should send an empty NOTIFY to the "presence"=20 subscription, and send a NOTIFY to the "presence.winfo" subscriber = telling=20 them that the subscription is waiting for their authorization. If the=20 subscription is a refresh of the pending "presence" subscription, then = you=20 need to send an empty NOTIFY to the "presence" subscription, but = it's a=20 MAY notify on the "presence.winfo" side (the = renotification may not=20 be particularly useful).
 
 
I=20 think the new version of the events draft is supposed to be sent out = today, so=20 maybe that'll provide more clarification.
 
Thoughts?
 
Regards,
 
Brian Stucker
-----Original Message-----
From: Ngo, Dai (c)=20 [mailto:c-Dai.Ngo@WCOM.Com]
Sent: Thursday, November 01, = 2001=20 10:27 AM
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier = Lachlan';=20 Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul = Kyzivat';=20 Jonathan Rosenberg
Cc: simple
Subject: RE: = [Simple] 200=20 vs. 202

While = reviewing the=20 draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 = "The=20 Watcherinfo State Machine" it says, "If, when a subscription = arrives, there=20 is no authorization policy in existence, the subscription moves into = the=20 pending state. In this state, the server is awaiting an = authorization=20 decision. *No notifications are = generated*, but the subscription FSM is=20 maintained."

It seems = to me that=20 the above statement contradicts with what we are saying here, that = an empty=20 notification is needed to complete the three-ways=20 handshake.

 

How do we = reconcile=20 this conflict?

 

--=20 Dai

 

 

 

-----Original=20 Message-----
From: Brian=20 Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, October 09, = 2001 2:27=20 PM
To: Ngo, Dai = (c);=20 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; = 'ext=20 Paul Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. = 202

 

Maybe=20 the confusion that we're having is centered around how to deal with=20 an
empty=20 NOTIFY. If you think of an empty NOTIFY as signifying nothing about=20 the
status of=20 the subscription (pending or accepted) and nothing about the=20 state
of the=20 resource the subscription is made to (in this case the presence=20 agent),
then=20 things get a lot simpler.

If you=20 think about it that way, then the processing of an empty NOTIFY=20 creates
a=20 three-way handshake to the subscription request, and that helps with = forking
issues.

If the=20 events draft is updated to clarify this thinking (assuming that this = is=20
the = behaviour=20 desired), and the presence draft is updated such that an=20 *empty*
NOTIFY,=20 and not one with bogus information in it, is sent after a 202, then=20 I
think things=20 will get a lot less fuzzy.

Jonathan? Adam? =

Brian

-----Original Message----- =
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]<= /FONT>=20
Sent: Tuesday, = October 09,=20 2001 8:32 AM
To: 'Brazier Lachlan'; Stucker, Brian=20 [NGB:B621:EXCH]; Moran Tim
(NET/Dallas); adam.roach; James Undery; = 'ext Paul=20 Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. = 202=20

 

In=20 section 5.2.3 "Notifier NOTIFY Behavior" of=20 draft-ietf-sip-events-00.txt
from Adam Roach, it states, "When a = SUBSCRIBE=20 request is successfully
processed or a relevant change in the = subscribed=20 state occurs, the notifier
will construct and send a NOTIFY request = to the=20 subscribers, as specified in
the contact field of the SUBSCRIBE = request. Such a=20 message should be sent in
as timely a manner as is = practical".=20

In=20 section 5.8 "Notifier Generation of NOTIFY Requests" = of=20
draft-ietf-simple-presence-03.txt it = states, "If a=20 subscription is accepted
(or politely blocked) a NOTIFY must be = sent after=20 the 200 OK response to the
SUBSCRIBE has been sent. Notifications MAY = be sent=20 at later times, possibly
when the presence state of the presentity=20 changes."

It=20 makes more sense to NOT sending the empty NOTIFY after a = 202.=20

Regards,

-- Dai=20 Ngo

-----Original Message----- =
From: Brazier Lachlan [mailto:lachlan.brazier@siemens= .at]=20
Sent: Tuesday,=20 October 09, 2001 3:29 AM
To: 'Brian Stucker'; Moran Tim = (NET/Dallas);=20 adam.roach; James Undery; Ngo,
Dai (c); 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc:=20 simple
Subject:=20 AW: [Simple] 200 vs. 202

Hello,
 
When a subscriber receives a 200 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's from = other=20 senders will be responded to
with an error (481). The tags in the FROM = header of=20 these NOTIFY's are
different than the tag in the To header in = the=20 response to the SUBSCRIBE.
 
When a subscriber receives a 202 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's from = other=20 senders will be responded to
with an error (481). The tags in the FROM = header of=20 these NOTIFY's are
different than the tag in the To header in = the=20 response to the SUBSCRIBE.
 
 
The question is now, when is the = presentity sending=20 the NOTIFY?
 
If a 200 Ok was returned to the SUBSCRIBE = request,=20 the PA of the presentity
knows the status of the presentity. If a = 202=20 Accepted was returned, it
doesn't know right now, but it can find=20 out.
 
I believe that a NOTIFY must be sent = "immediately"=20 after sending a 2xx
response to the subscriber. What does = "immediately=20 mean"? Does it mean
sending the NOTIFY without delay, or does = it mean=20 sending the NOTIFY when
the status is obtained by the = PA?=20
 =20
If "immediately" = means after=20 obtaining the status, I don't see the problem. =
  =
If "immediately" means = without delay,=20 the first NOTIFY after sending a 202
will be useless. I've looked in the = presence=20 draft
(draft-ietf-simple-presence-03.txt), but I = haven't=20 found the phrase stating,
that a NOTIFY MUST be sent immediately = after sending=20 a 202 Acepted. I only
found it for 200 Ok. =
Still, as 202 Accepted is a = positive=20 response, the NOTIFY could be required. =

This=20 leads to my next question: Why is it required? =
Anyway, to follow the = requirements, I=20 always can send an empty NOTIFY.
 
 
Please correct me, when I stated something = wrong or=20 missunderstood
something!
 
Lachlan
 
 

-----Urspr=FCngliche = Nachricht-----=20
Von: Brian = Stucker [mailto:bstucker@nortelnetwork= s.com]=20
Gesendet am: = Dienstag, 09.=20 Oktober 2001 01:34
An: Moran Tim (NET/Dallas); adam.roach; = James=20 Undery; Ngo, Dai (c); 'ext
Paul Kyzivat'; Jonathan = Rosenberg=20
Cc: = simple=20
Betreff: RE: = [Simple] 200 vs.=20 202

 

It is=20 my understanding that if the 200 OK is dropped to a SUBSCRIBE,=20 the
watcher=20 must reject the subsequent NOTIFY because it never saw what the=20 TO
tag was from=20 the response to the SUBSCRIBE (because it was in the 200 = OK).=20
You could argue = that the=20 watcher takes the TO tag in the first response or =
NOTIFY it gets back (as = long as the=20 FROM tag and everything else matches
ok). However, that seems to be a bit = dangerous if we=20 consider cases where
multiple packets are being dropped = (unintentionally=20 or otherwise).

Forking=20 subscriptions seems to be problematic at best unless you ACK=20 the
response=20 (as Adam pointed out with the 3-way handshake mention) like = an=20
INVITE does = instead of=20 relying on a NOTIFY that does nothing because CPIM =
wants it. It's coming from = the wrong=20 endpoint, as you say. I would think
that anything that forks, and creates a = meta-session=20 routing requirement
needs to be ACK'd. =

Brian=20 Stucker

 

-----Original Message----- =
From: Moran Tim = (NET/Dallas) [ mailto:Tim.Moran@nokia.com= =20
<mailto:Tim.Moran@nokia.com> ] =
Sent: Monday,=20 October 08, 2001 6:17 PM
To: adam.roach; Stucker, Brian = [NGB:B621:EXCH];=20 James Undery; Ngo, Dai (c);
'ext Paul Kyzivat'; Jonathan Rosenberg=20
Cc: = simple=20
Subject: RE:=20 [Simple] 200 vs. 202

 

Three-way handshake in my dictionary = implies=20 A->B, A<-B, and then a A->B
again. This is not the case in a = Subscribe, 200/202=20 and then a Notify in
the same direction as the 2xx.. I am also = puzzled by=20 your "immediate"
requirement after a 202 since your own = draft uses=20 phrases like ...

A 202=20 response indicates that there may be a sizable delay before = a=20
notification is = received,=20 pending the actual creation of the subscription=20

If the=20 notifier owner is interactively queried to determine whether = a=20
subscription is = allowed, a=20 "202 Accept" response is returned immediately, =
and the subsequent NOTIFY = request is=20 suppressed until the notifier  owner
responds. =

Does=20 the requirement for an immediate notify after a 202 only apply=20 to
forked=20 requests? How does the server know when a request has been=20 forked?

So=20 let's say a Subscribe is forked and all the PAs respond with 202.=20 The
best one is=20 returned to the watcher and the rest dropped. All of the = PAs=20
must also respond = with a=20 Notify with useless information which the proxy =
passes on. How enlightened = is the=20 watcher upon receiving the dummy
Notifications? What change is there in the = state=20 machine? Then there is the
scenario of 202s come back, proxy timer = expires so=20 the best 202 is sent back
to watcher - and then a 200 comes. I = presume it=20 would be dropped. The PA
which sent the 200 sends a Notify = (immediately)=20 which is forwarded but there
is no preceding 200 so the watcher drops = it? =20 There is the out-of-sequence
clause, but if the 200 never appears = wouldn't the=20 notify be rejected? Nodes
which know they can't authorize at the = time of=20 subscription may respond
quicker than the node which is actually = doing the=20 work of obtaining
authorization. Sounds like some guidelines = are=20 needed as to how fast is
immediate and how long a proxy waits for = that 200=20 with the immediate notify.

Tim M.=20

>=20 -----Original Message-----
> From: ext adam.roach@ericsson.com [ = mailto:adam.roach@ericsson.com=20
<mailto:adam.roach@ericsson.com>=20 ]
> Sent:=20 Monday, October 08, 2001 2:12 PM
> To: 'Brian Stucker'; James Undery; = Ngo, Dai=20 (c); Moran Tim
> (NET/Dallas);
> 'ext Paul Kyzivat'; = Jonathan=20 Rosenberg
>=20 Cc: simple
>=20 Subject: RE: [Simple] 200 vs. 202
>
>
> Sorry; I haven't been following this = closely=20 (things have been
> hellishly busy recently). This = conversation,=20 though, seems to
> have taken a dangerous turn.=20
>=20
> Remember=20 that the behaviour of SUB/NOT is general, and not just=20
> related to=20 presence. And, in the general case, forking of SUBSCRIBEs=20
> can be=20 extremely useful.
>
> However, without a three-way = handshake, such=20 forking becomes quite
> messy and unpleasant to implement.=20
>=20
> The=20 immediate NOTIFY is the third message of this three-way handshake.=20
> It can't=20 be removed from the base SUB/NOT draft; by extension, the use=20
> of SUB/NOT=20 for presence needs to keep it.
>
> /a
>
>
> -----Original Message-----=20
> From:=20 Brian Stucker [ mailto:bstucker@nortelnetwork= s.com=20
<mailto:bstucker@nortelnetwork= s.com>=20 ]
> Sent:=20 Monday, October 08, 2001 1:54 PM
> To: James Undery; Ngo, Dai (c); = 'Moran Tim=20 (NET/Dallas)';
> 'ext Paul Kyzivat'; =
> Jonathan Rosenberg=20
> Cc: simple=20
> Subject:=20 RE: [Simple] 200 vs. 202
>
>
> Ok, as a compromise, since we all = seem to feel=20 that the
>=20 NOTIFY after a 202 is
> totally useless... =
> Can't we make the 202 = act as an=20 implied 'Offline' (or some
> other harmless, and =
> meaningless = indication)=20
> NOTIFY=20 within the context of how CPIM requirements work in a=20
> SIP=20 network?
>=20 Gateway functions to other
> protocols can generate whatever = messages they=20 want from this,
> but in the
> context of what gets sent=20
> around in=20 a SIP network, the 202 acts as a NOTIFY itself. =
> Heck, you could even = put dummy XML=20 in the 202 message body if
> you really wanted =
> (but I'd rather not).=20
> Brian=20 Stucker
>=20 -----Original Message-----
> From: James Undery [ mailto:jundery@ubiquity.net=20
<mailto:jundery@ubiquity.net> = ]=20
> Sent:=20 Monday, October 08, 2001 5:12 AM
> To: Ngo, Dai (c); 'Moran Tim = (NET/Dallas)';=20 'ext Paul
>=20 Kyzivat'; Jonathan
> Rosenberg
> Cc: simple
> Subject: RE: [Simple] 200 vs. 202=20
>=20
>=20
> I'd like=20 to agree with you too, unfortunately it's a CPIM requirement=20
> as 2xx are=20 successful responses. The SIMPLE charter requires CPIM=20
>=20 complience.
> James
> -----Original Message-----=20
> From:=20 simple-admin@mailman.dynamicsoft.com
> [ mailto:simple-admin@= mailman.dynamicsoft.com=20
<mailto:simple-admin@= mailman.dynamicsoft.com>=20 ]On Behalf Of Ngo, Dai (c)
> Sent: 05 October 2001 17:52=20
> To: 'Moran=20 Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg=20
> Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
>=20
>=20
> I agree=20 that there is no need to send an immediate, empty NOTIFY after=20
> a 202 was=20 sent in the pending case.
> -- Dai
> -----Original Message-----=20
> From:=20 Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com= =20
<mailto:Tim.Moran@nokia.com> ] =
> Sent:=20 Friday, October 05, 2001 10:33 AM
> To: 'ext Paul Kyzivat'; Jonathan = Rosenberg=20
> Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
> My=20 comments are in line.
> > -----Original Message-----=20
> > From:=20 ext Paul Kyzivat [ mailto:pkyzivat@cisco.com=20
<mailto:pkyzivat@cisco.com> = ]=20
> > Sent:=20 Friday, October 05, 2001 8:04 AM
> > To: Jonathan Rosenberg=20
> > Cc:=20 Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com=20
> >=20 Subject: Re: [Simple] 200 vs. 202
> >
> >
> Seems you are both saying the same = thing. I=20 seem to recall an earlier
> dialogue where it was stated that = non-Invite=20 requests are treated
> differently than Invites in that only = one=20 response in sent back to the
> "Subscriber" in this case.  So = it would=20 appear that the PA (with proxy
> capabilities) will wait some = predetermined=20 amount of time to collect
> all of the responses (or until all = are received=20 whichever comes first)
> and send back the best response. If = the best is=20 a 202, then does the
> proxy wait for the Notify and send = the=20 202+Notify or just the 202 and
> the Notify later? I guess I don't see = the need=20 for a 202 indicating
> pending followed immediately by = another message=20 (Notify with no real
> status) which adds no value.=20
>=20
>=20
>=20
>=20 _______________________________________________ =
> simple mailing list=20
>=20 simple@mailman.dynamicsoft.com
> http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple=20
<http://ma= ilman.dynamicsoft.com/mailman/listinfo/simple> =20
>=20 =

------_=_NextPart_001_01C162FB.AA81F77C-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 13:46:54 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27328 for ; Thu, 1 Nov 2001 13:46:53 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1IiUb7028593; Thu, 1 Nov 2001 13:44:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17444; Thu, 1 Nov 2001 13:46:03 -0500 (EST) 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 NAA17432 for ; Thu, 1 Nov 2001 13:45:42 -0500 (EST) 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 fA1Ii9b7028589 for ; Thu, 1 Nov 2001 13:44:09 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 13:45:25 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E744@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks 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] Administrative note - post contents 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, 1 Nov 2001 13:45:22 -0500 Folks - We're starting to see some grossly oversized messages on the list. Please edit your replies to include only pertainant material - including the whole message is wasteful. It would also help to post plain text only. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 13:48:28 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27381 for ; Thu, 1 Nov 2001 13:48:27 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1IjYb7028666; Thu, 1 Nov 2001 13:45:34 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17477; Thu, 1 Nov 2001 13:47:07 -0500 (EST) 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 NAA17402 for ; Thu, 1 Nov 2001 13:41:09 -0500 (EST) 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 MAA05299 for ; Thu, 1 Nov 2001 12:40:51 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 1 Nov 2001 12:34:00 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 12:40:04 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EA70851@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Moran Tim (NET/Dallas)" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , James Undery , "'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_01C16304.A1446E40" 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: Thu, 1 Nov 2001 12:40:07 -0600 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_01C16304.A1446E40 Content-Type: text/plain; charset="iso-8859-1" Forking interactions, for one. The NOTIFY is used to clear out the subscriptions that may have been created on nodes that the SUBSCRIBE got forked to, but whose response was not forwarded back to the UAC that sent the original SUBSCRIBE. 202 Pending means you've been authenticated, but not authorized yet. You can't send back a dummy (meaning a NOTIFY containing a message body) back, because that's how you signal to the subscriber that their subscription has been authorized finally (authorization triggers a NOTIFY with a message body). Thus, sending a NOTIFY back that is empty takes care of the 3-way handshake requirement, but doesn't trick the user into thinking that a subscription was authorized when it wasn't. You way basically causes the client to ping the network incessantly asking if their subscription has been authorized yet: "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?".... Seems wasteful, given that you can simply send back an empty NOTIFY, and be done with it. Your solution also does not take care of cleaning up forking interactions if I understand it correctly. The three-way handshake is in the events draft, and it works. The only issue that I can see are getting the presence and watcherinfo drafts on board with what the events draft has set forth, and just clarifying the text in the events draft a little. It's not a big change in my view. Regards, Brian -----Original Message----- From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com] Sent: Thursday, November 01, 2001 11:36 AM To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 To me the term Pending (as in 202 Pending) says hold on I can not answer right now. Sorry, but I just don't see the justification in the immediate dummy message to the receiver of the 202. I understand (think I do) that the empty Notify request is sent so that the notifier can know that the 202 was received because it causes a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake. It would appear the assumption is that 3-way handshake is required. What is wrong with the subscriber timing out on receiving a response from the notifer (200 or 202) and resending the subscribe? That is, what is wrong with a two-way handshake with a timer? Tim M. -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 10:49 AM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. Thoughts? Regards, Brian Stucker -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, November 01, 2001 10:27 AM To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. How do we reconcile this conflict? -- Dai -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, October 09, 2001 2:27 PM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 Maybe the confusion that we're having is centered around how to deal with an empty NOTIFY. If you think of an empty NOTIFY as signifying nothing about the status of the subscription (pending or accepted) and nothing about the state of the resource the subscription is made to (in this case the presence agent), then things get a lot simpler. If you think about it that way, then the processing of an empty NOTIFY creates a three-way handshake to the subscription request, and that helps with forking issues. If the events draft is updated to clarify this thinking (assuming that this is the behaviour desired), and the presence draft is updated such that an *empty* NOTIFY, and not one with bogus information in it, is sent after a 202, then I think things will get a lot less fuzzy. Jonathan? Adam? Brian -----Original Message----- From: Ngo, Dai (c) [ mailto:c-Dai.Ngo@WCOM.Com ] Sent: Tuesday, October 09, 2001 8:32 AM To: 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-00.txt from Adam Roach, it states, "When a SUBSCRIBE request is successfully processed or a relevant change in the subscribed state occurs, the notifier will construct and send a NOTIFY request to the subscribers, as specified in the contact field of the SUBSCRIBE request. Such a message should be sent in as timely a manner as is practical". In section 5.8 "Notifier Generation of NOTIFY Requests" of draft-ietf-simple-presence-03.txt it states, "If a subscription is accepted (or politely blocked) a NOTIFY must be sent after the 200 OK response to the SUBSCRIBE has been sent. Notifications MAY be sent at later times, possibly when the presence state of the presentity changes." It makes more sense to NOT sending the empty NOTIFY after a 202. Regards, -- Dai Ngo -----Original Message----- From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ] Sent: Tuesday, October 09, 2001 3:29 AM To: 'Brian Stucker'; Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: AW: [Simple] 200 vs. 202 Hello, When a subscriber receives a 200 on a SUBSCRIBE request, a NOTIFY from the presentity can be handled. NOTIFY's from other senders will be responded to with an error (481). The tags in the FROM header of these NOTIFY's are different than the tag in the To header in the response to the SUBSCRIBE. When a subscriber receives a 202 on a SUBSCRIBE request, a NOTIFY from the presentity can be handled. NOTIFY's from other senders will be responded to with an error (481). The tags in the FROM header of these NOTIFY's are different than the tag in the To header in the response to the SUBSCRIBE. The question is now, when is the presentity sending the NOTIFY? If a 200 Ok was returned to the SUBSCRIBE request, the PA of the presentity knows the status of the presentity. If a 202 Accepted was returned, it doesn't know right now, but it can find out. I believe that a NOTIFY must be sent "immediately" after sending a 2xx response to the subscriber. What does "immediately mean"? Does it mean sending the NOTIFY without delay, or does it mean sending the NOTIFY when the status is obtained by the PA? If "immediately" means after obtaining the status, I don't see the problem. If "immediately" means without delay, the first NOTIFY after sending a 202 will be useless. I've looked in the presence draft (draft-ietf-simple-presence-03.txt), but I haven't found the phrase stating, that a NOTIFY MUST be sent immediately after sending a 202 Acepted. I only found it for 200 Ok. Still, as 202 Accepted is a positive response, the NOTIFY could be required. This leads to my next question: Why is it required? Anyway, to follow the requirements, I always can send an empty NOTIFY. Please correct me, when I stated something wrong or missunderstood something! Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] Gesendet am: Dienstag, 09. Oktober 2001 01:34 An: Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Betreff: RE: [Simple] 200 vs. 202 It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, the watcher must reject the subsequent NOTIFY because it never saw what the TO tag was from the response to the SUBSCRIBE (because it was in the 200 OK). You could argue that the watcher takes the TO tag in the first response or NOTIFY it gets back (as long as the FROM tag and everything else matches ok). However, that seems to be a bit dangerous if we consider cases where multiple packets are being dropped (unintentionally or otherwise). Forking subscriptions seems to be problematic at best unless you ACK the response (as Adam pointed out with the 3-way handshake mention) like an INVITE does instead of relying on a NOTIFY that does nothing because CPIM wants it. It's coming from the wrong endpoint, as you say. I would think that anything that forks, and creates a meta-session routing requirement needs to be ACK'd. Brian Stucker -----Original Message----- From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com < mailto:Tim.Moran@nokia.com > ] Sent: Monday, October 08, 2001 6:17 PM To: adam.roach; Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 Three-way handshake in my dictionary implies A->B, A<-B, and then a A->B again. This is not the case in a Subscribe, 200/202 and then a Notify in the same direction as the 2xx.. I am also puzzled by your "immediate" requirement after a 202 since your own draft uses phrases like ... A 202 response indicates that there may be a sizable delay before a notification is received, pending the actual creation of the subscription If the notifier owner is interactively queried to determine whether a subscription is allowed, a "202 Accept" response is returned immediately, and the subsequent NOTIFY request is suppressed until the notifier owner responds. Does the requirement for an immediate notify after a 202 only apply to forked requests? How does the server know when a request has been forked? So let's say a Subscribe is forked and all the PAs respond with 202. The best one is returned to the watcher and the rest dropped. All of the PAs must also respond with a Notify with useless information which the proxy passes on. How enlightened is the watcher upon receiving the dummy Notifications? What change is there in the state machine? Then there is the scenario of 202s come back, proxy timer expires so the best 202 is sent back to watcher - and then a 200 comes. I presume it would be dropped. The PA which sent the 200 sends a Notify (immediately) which is forwarded but there is no preceding 200 so the watcher drops it? There is the out-of-sequence clause, but if the 200 never appears wouldn't the notify be rejected? Nodes which know they can't authorize at the time of subscription may respond quicker than the node which is actually doing the work of obtaining authorization. Sounds like some guidelines are needed as to how fast is immediate and how long a proxy waits for that 200 with the immediate notify. Tim M. > -----Original Message----- > From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com < mailto:adam.roach@ericsson.com > ] > Sent: Monday, October 08, 2001 2:12 PM > To: 'Brian Stucker'; James Undery; Ngo, Dai (c); Moran Tim > (NET/Dallas); > 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > Sorry; I haven't been following this closely (things have been > hellishly busy recently). This conversation, though, seems to > have taken a dangerous turn. > > Remember that the behaviour of SUB/NOT is general, and not just > related to presence. And, in the general case, forking of SUBSCRIBEs > can be extremely useful. > > However, without a three-way handshake, such forking becomes quite > messy and unpleasant to implement. > > The immediate NOTIFY is the third message of this three-way handshake. > It can't be removed from the base SUB/NOT draft; by extension, the use > of SUB/NOT for presence needs to keep it. > > /a > > > -----Original Message----- > From: Brian Stucker [ mailto:bstucker@nortelnetworks.com < mailto:bstucker@nortelnetworks.com > ] > Sent: Monday, October 08, 2001 1:54 PM > To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; > 'ext Paul Kyzivat'; > Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > Ok, as a compromise, since we all seem to feel that the > NOTIFY after a 202 is > totally useless... > Can't we make the 202 act as an implied 'Offline' (or some > other harmless, and > meaningless indication) > NOTIFY within the context of how CPIM requirements work in a > SIP network? > Gateway functions to other > protocols can generate whatever messages they want from this, > but in the > context of what gets sent > around in a SIP network, the 202 acts as a NOTIFY itself. > Heck, you could even put dummy XML in the 202 message body if > you really wanted > (but I'd rather not). > Brian Stucker > -----Original Message----- > From: James Undery [ mailto:jundery@ubiquity.net < mailto:jundery@ubiquity.net > ] > Sent: Monday, October 08, 2001 5:12 AM > To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul > Kyzivat'; Jonathan > Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > I'd like to agree with you too, unfortunately it's a CPIM requirement > as 2xx are successful responses. The SIMPLE charter requires CPIM > complience. > James > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [ mailto:simple-admin@mailman.dynamicsoft.com < mailto:simple-admin@mailman.dynamicsoft.com > ]On Behalf Of Ngo, Dai (c) > Sent: 05 October 2001 17:52 > To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 200 vs. 202 > > > I agree that there is no need to send an immediate, empty NOTIFY after > a 202 was sent in the pending case. > -- Dai > -----Original Message----- > From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com < mailto:Tim.Moran@nokia.com > ] > Sent: Friday, October 05, 2001 10:33 AM > To: 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 200 vs. 202 > My comments are in line. > > -----Original Message----- > > From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com < mailto:pkyzivat@cisco.com > ] > > Sent: Friday, October 05, 2001 8:04 AM > > To: Jonathan Rosenberg > > Cc: Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] 200 vs. 202 > > > > > Seems you are both saying the same thing. I seem to recall an earlier > dialogue where it was stated that non-Invite requests are treated > differently than Invites in that only one response in sent back to the > "Subscriber" in this case. So it would appear that the PA (with proxy > capabilities) will wait some predetermined amount of time to collect > all of the responses (or until all are received whichever comes first) > and send back the best response. If the best is a 202, then does the > proxy wait for the Notify and send the 202+Notify or just the 202 and > the Notify later? I guess I don't see the need for a 202 indicating > pending followed immediately by another message (Notify with no real > status) which adds no value. > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple < http://mailman.dynamicsoft.com/mailman/listinfo/simple > > ------_=_NextPart_001_01C16304.A1446E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202
Forking interactions, for one. The NOTIFY is used to clear out = the=20 subscriptions that may have been created on nodes that the SUBSCRIBE = got forked=20 to, but whose response was not forwarded back to the UAC that sent the = original=20 SUBSCRIBE.
 
202=20 Pending means you've been authenticated, but not authorized yet. You = can't send=20 back a dummy (meaning a NOTIFY containing a message body) back, because = that's=20 how you signal to the subscriber that their subscription has been = authorized=20 finally (authorization triggers a NOTIFY with a message body). Thus, = sending a=20 NOTIFY back that is empty takes care of the 3-way handshake = requirement, but=20 doesn't trick the user into thinking that a subscription was authorized = when it=20 wasn't.
 
You=20 way basically causes the client to ping the network incessantly asking = if their=20 subscription has been authorized yet: "Am I authorized yet?", "Am I = authorized=20 yet?", "Am I authorized yet?", "Am I authorized yet?".... Seems = wasteful, given=20 that you can simply send back an empty NOTIFY, and be done with it. = Your=20 solution also does not take care of cleaning up forking interactions if = I=20 understand it correctly.
 
The=20 three-way handshake is in the events draft, and it works. The only = issue that I=20 can see are getting the presence and watcherinfo drafts on board with = what the=20 events draft has set forth, and just clarifying the text in the events = draft a=20 little. It's not a big change in my view.
 
Regards,
 
Brian
-----Original Message-----
From: Moran Tim = (NET/Dallas)=20 [mailto:Tim.Moran@nokia.com]
Sent: Thursday, November 01, = 2001 11:36=20 AM
To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); = 'Brazier=20 Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

To=20 me the term Pending (as in 202 Pending) says hold on I can not = answer=20 right now. Sorry, but I just don't see the justification in the = immediate=20 dummy message to the receiver of the 202. I understand (think I do) = that the=20 empty Notify request is sent so that the notifier can know that the = 202 was=20 received because it causes a 200 from Subscriber to Notifier. 4 = messages to do=20 a 3 way handshake.
 
It=20 would appear the assumption is that 3-way handshake is required.=20 What is wrong with the subscriber timing out on receiving a = response=20 from the notifer (200 or 202) and resending the subscribe? That is, = what is=20 wrong with a  two-way handshake with a = timer?
 
Tim=20 M.
-----Original Message-----
From: ext Brian = Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, = November 01,=20 2001 10:49 AM
To: Ngo, Dai (c); 'Brazier Lachlan'; Moran = Tim=20 (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; = Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

The wording there can be taken several ways, and probably = needs to be=20 clarified. We really need to be talking about two notifications at = the point=20 at which a pending subscription comes in: notifying the client that = has a=20 event-package.winfo subscription, and notifying the client that is=20 requesting the new event-package subscription (where in this case,=20 event-package is likely to be "presence").
 
I=20 would argue that you should send an empty NOTIFY to the "presence"=20 subscription, and send a NOTIFY to the "presence.winfo" subscriber = telling=20 them that the subscription is waiting for their authorization. If = the=20 subscription is a refresh of the pending "presence" subscription, = then you=20 need to send an empty NOTIFY to the "presence" subscription, but = it's a=20 MAY notify on the "presence.winfo" side (the = renotification may=20 not be particularly useful).
 
 
I=20 think the new version of the events draft is supposed to be sent = out today,=20 so maybe that'll provide more clarification.
 
Thoughts?
 
Regards,
 
Brian Stucker
-----Original Message-----
From: Ngo, Dai (c)=20 [mailto:c-Dai.Ngo@WCOM.Com]
Sent: Thursday, November = 01, 2001=20 10:27 AM
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier = Lachlan';=20 Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul = Kyzivat';=20 Jonathan Rosenberg
Cc: simple
Subject: RE: = [Simple]=20 200 vs. 202

While = reviewing=20 the draft "draft-ietf-simple-winfo-package-00.txt" in the section = 3.6.1=20 "The Watcherinfo State Machine" it says, "If, when a subscription = arrives,=20 there is no authorization policy in existence, the subscription = moves into=20 the pending state. In this state, the server is awaiting an = authorization=20 decision. *No notifications = are=20 generated*, but the subscription FSM is=20 maintained."

It = seems to me=20 that the above statement contradicts with what we are saying = here, that an=20 empty notification is needed to complete the three-ways=20 handshake.

 

How do = we=20 reconcile this conflict?

 

--=20 Dai

 

 

 

-----Original=20 Message-----
From: Brian=20 Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, October 09, = 2001 2:27=20 PM
To: Ngo, = Dai (c);=20 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James = Undery; 'ext=20 Paul Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

 

Maybe=20 the confusion that we're having is centered around how to deal = with=20 an
empty=20 NOTIFY. If you think of an empty NOTIFY as signifying nothing = about=20 the
status of=20 the subscription (pending or accepted) and nothing about the=20 state
of the=20 resource the subscription is made to (in this case the presence=20 agent),
then=20 things get a lot simpler.

If=20 you think about it that way, then the processing of an empty = NOTIFY=20 creates
a=20 three-way handshake to the subscription request, and that helps = with=20 forking
issues.

If=20 the events draft is updated to clarify this thinking (assuming = that this=20 is
the=20 behaviour desired), and the presence draft is updated such that = an=20 *empty*
NOTIFY, and not one with bogus = information in it,=20 is sent after a 202, then I
think things will get a lot less=20 fuzzy.

Jonathan? Adam? =

Brian

-----Original = Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]= =20
Sent: Tuesday, = October 09,=20 2001 8:32 AM
To: 'Brazier Lachlan'; Stucker, Brian=20 [NGB:B621:EXCH]; Moran Tim
(NET/Dallas); adam.roach; James Undery; = 'ext Paul=20 Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. = 202=20

 

In=20 section 5.2.3 "Notifier NOTIFY Behavior" of=20 draft-ietf-sip-events-00.txt
from Adam Roach, it states, "When a = SUBSCRIBE=20 request is successfully
processed or a relevant change in the = subscribed=20 state occurs, the notifier
will construct and send a NOTIFY = request to the=20 subscribers, as specified in
the contact field of the SUBSCRIBE = request. Such a=20 message should be sent in
as timely a manner as is = practical".=20

In=20 section 5.8 "Notifier Generation of NOTIFY Requests" = of=20
draft-ietf-simple-presence-03.txt it = states, "If a=20 subscription is accepted
(or politely blocked) a NOTIFY must be = sent after=20 the 200 OK response to the
SUBSCRIBE has been sent. Notifications = MAY be sent=20 at later times, possibly
when the presence state of the = presentity=20 changes."

It=20 makes more sense to NOT sending the empty NOTIFY after a=20 202.

Regards,

--=20 Dai Ngo

-----Original = Message-----
From: Brazier Lachlan = [mailto:lachlan.brazier@= siemens.at]=20
Sent:=20 Tuesday, October 09, 2001 3:29 AM
To: 'Brian Stucker'; Moran Tim = (NET/Dallas);=20 adam.roach; James Undery; Ngo,
Dai (c); 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc:=20 simple
Subject: AW: [Simple] 200 vs. = 202=20

Hello,
 
When a subscriber receives a 200 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's = from other=20 senders will be responded to
with an error (481). The tags in the = FROM header=20 of these NOTIFY's are
different than the tag in the To header = in the=20 response to the SUBSCRIBE.
 
When a subscriber receives a 202 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's = from other=20 senders will be responded to
with an error (481). The tags in the = FROM header=20 of these NOTIFY's are
different than the tag in the To header = in the=20 response to the SUBSCRIBE.
 
 
The question is now, when is the = presentity=20 sending the NOTIFY?
 
If a 200 Ok was returned to the = SUBSCRIBE request,=20 the PA of the presentity
knows the status of the presentity. If = a 202=20 Accepted was returned, it
doesn't know right now, but it can find = out.
 
I believe that a NOTIFY must be sent = "immediately"=20 after sending a 2xx
response to the subscriber. What does = "immediately=20 mean"? Does it mean
sending the NOTIFY without delay, or = does it mean=20 sending the NOTIFY when
the status is obtained by the = PA?=20
 =20
If = "immediately" means=20 after obtaining the status, I don't see the = problem.=20
 =20
If = "immediately" means=20 without delay, the first NOTIFY after sending a 202 =
will be = useless. I've=20 looked in the presence draft
(draft-ietf-simple-presence-03.txt), = but I haven't=20 found the phrase stating,
that a NOTIFY MUST be sent immediately = after=20 sending a 202 Acepted. I only
found it for 200 Ok. =
Still, as 202 Accepted = is a positive=20 response, the NOTIFY could be required. =

This=20 leads to my next question: Why is it required? =
Anyway, to follow the = requirements, I=20 always can send an empty NOTIFY.
 
 
Please correct me, when I stated = something wrong=20 or missunderstood
something!
 
Lachlan
 
 

-----Urspr=FCngliche = Nachricht-----=20
Von: Brian = Stucker [mailto:bstucker@nortelnetwor= ks.com]=20
Gesendet am: = Dienstag, 09.=20 Oktober 2001 01:34
An: Moran Tim (NET/Dallas); adam.roach; = James=20 Undery; Ngo, Dai (c); 'ext
Paul Kyzivat'; Jonathan = Rosenberg=20
Cc: = simple=20
Betreff: RE: = [Simple] 200=20 vs. 202

 

It is=20 my understanding that if the 200 OK is dropped to a SUBSCRIBE,=20 the
watcher=20 must reject the subsequent NOTIFY because it never saw what the=20 TO
tag was=20 from the response to the SUBSCRIBE (because it was in the 200=20 OK).
You=20 could argue that the watcher takes the TO tag in the first = response=20 or
NOTIFY it=20 gets back (as long as the FROM tag and everything else=20 matches
ok).=20 However, that seems to be a bit dangerous if we consider cases=20 where
multiple packets are being dropped=20 (unintentionally or otherwise).

Forking subscriptions seems to be = problematic at=20 best unless you ACK the
response (as Adam pointed out with the = 3-way=20 handshake mention) like an
INVITE does instead of relying on a = NOTIFY that=20 does nothing because CPIM
wants it. It's coming from the wrong = endpoint, as=20 you say. I would think
that anything that forks, and creates a = meta-session routing requirement
needs to be ACK'd. =

Brian=20 Stucker

 

-----Original Message----- =
From: Moran Tim = (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20
<mailto:Tim.Moran@nokia.com> = ]=20
Sent: Monday,=20 October 08, 2001 6:17 PM
To: adam.roach; Stucker, Brian = [NGB:B621:EXCH];=20 James Undery; Ngo, Dai (c);
'ext Paul Kyzivat'; Jonathan Rosenberg=20
Cc: simple=20
Subject: RE:=20 [Simple] 200 vs. 202

 

Three-way handshake in my dictionary = implies=20 A->B, A<-B, and then a A->B
again. This is not the case in a = Subscribe,=20 200/202 and then a Notify in
the same direction as the 2xx.. I am = also puzzled=20 by your "immediate"
requirement after a 202 since your own = draft uses=20 phrases like ...

A 202=20 response indicates that there may be a sizable delay before=20 a
notification is received, pending the = actual=20 creation of the subscription

If=20 the notifier owner is interactively queried to determine whether=20 a
subscription is allowed, a "202 Accept" = response=20 is returned immediately,
and the subsequent NOTIFY request is = suppressed=20 until the notifier  owner
responds.

Does=20 the requirement for an immediate notify after a 202 only apply=20 to
forked=20 requests? How does the server know when a request has been=20 forked?

So=20 let's say a Subscribe is forked and all the PAs respond with 202. = The
best one=20 is returned to the watcher and the rest dropped. All of the=20 PAs
must also=20 respond with a Notify with useless information which the=20 proxy
passes=20 on. How enlightened is the watcher upon receiving the = dummy=20
Notifications? = What change=20 is there in the state machine? Then there is the =
scenario of 202s come = back, proxy=20 timer expires so the best 202 is sent back =
to watcher - and then a = 200 comes. I=20 presume it would be dropped. The PA
which sent the 200 sends a Notify = (immediately)=20 which is forwarded but there
is no preceding 200 so the watcher = drops it? =20 There is the out-of-sequence
clause, but if the 200 never appears = wouldn't the=20 notify be rejected? Nodes
which know they can't authorize at the = time of=20 subscription may respond
quicker than the node which is actually = doing the=20 work of obtaining
authorization. Sounds like some = guidelines are=20 needed as to how fast is
immediate and how long a proxy waits = for that 200=20 with the immediate notify.

Tim=20 M.

>=20 -----Original Message-----
> From: ext adam.roach@ericsson.com = [ mailto:adam.roach@ericsson.com=20
<mailto:adam.roach@ericsson.com>=20 ]
> Sent:=20 Monday, October 08, 2001 2:12 PM
> To: 'Brian Stucker'; James Undery; = Ngo, Dai=20 (c); Moran Tim
> (NET/Dallas); =
> 'ext Paul Kyzivat'; = Jonathan=20 Rosenberg
> Cc: simple
> Subject: RE: = [Simple] 200 vs.=20 202
>=20
>=20
> Sorry; I=20 haven't been following this closely (things have been=20
>=20 hellishly busy recently). This conversation, though, seems to=20
> have=20 taken a dangerous turn.
>
> Remember that the behaviour of = SUB/NOT is=20 general, and not just
> related to presence. And, in the = general=20 case, forking of SUBSCRIBEs
> can be extremely useful.=20
>=20
> However,=20 without a three-way handshake, such forking becomes quite=20
> messy=20 and unpleasant to implement.
>
> The immediate NOTIFY is the third = message of=20 this three-way handshake.
> It can't be removed from the base = SUB/NOT=20 draft; by extension, the use
> of SUB/NOT for presence needs to = keep it.=20
>=20
> /a=20
>=20
>=20
>=20 -----Original Message-----
> From: Brian Stucker [ mailto:bstucker@nortelnetwor= ks.com=20
<mailto:bstucker@nortelnetwor= ks.com>=20 ]
> Sent:=20 Monday, October 08, 2001 1:54 PM
> To: James Undery; Ngo, Dai (c); = 'Moran Tim=20 (NET/Dallas)';
> 'ext Paul Kyzivat'; =
> Jonathan Rosenberg=20
> Cc:=20 simple
>=20 Subject: RE: [Simple] 200 vs. 202
>
>
> Ok, as a compromise, since we all = seem to=20 feel that the
> NOTIFY after a 202 is =
> totally useless...=20
> Can't we=20 make the 202 act as an implied 'Offline' (or some =
> other harmless, and =
>=20 meaningless indication)
> NOTIFY within the context of how = CPIM=20 requirements work in a
> SIP network? =
> Gateway functions = to other=20
>=20 protocols can generate whatever messages they want from this,=20
> but in=20 the
>=20 context of what gets sent
> around in a SIP network, the 202 = acts as a=20 NOTIFY itself.
> Heck, you could even put dummy XML = in the 202=20 message body if
> you really wanted =
> (but I'd rather = not).=20
> Brian=20 Stucker
>=20 -----Original Message-----
> From: James Undery [ mailto:jundery@ubiquity.net=20
<mailto:jundery@ubiquity.net>= ]=20
> Sent:=20 Monday, October 08, 2001 5:12 AM
> To: Ngo, Dai (c); 'Moran Tim = (NET/Dallas)';=20 'ext Paul
> Kyzivat'; Jonathan =
> Rosenberg=20
> Cc:=20 simple
>=20 Subject: RE: [Simple] 200 vs. 202
>
>
> I'd like to agree with you too, = unfortunately=20 it's a CPIM requirement
> as 2xx are successful responses. = The SIMPLE=20 charter requires CPIM
> complience. =
> James =
> -----Original = Message-----=20
> From:=20 simple-admin@mailman.dynamicsoft.com
> [ mailto:simple-admin= @mailman.dynamicsoft.com=20
<mailto:simple-admin= @mailman.dynamicsoft.com>=20 ]On Behalf Of Ngo, Dai (c)
> Sent: 05 October 2001 17:52=20
> To:=20 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg=20
> Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
>=20
>=20
> I agree=20 that there is no need to send an immediate, empty NOTIFY after=20
> a 202=20 was sent in the pending case.
> -- Dai
> -----Original Message-----=20
> From:=20 Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20
<mailto:Tim.Moran@nokia.com> = ]=20
> Sent:=20 Friday, October 05, 2001 10:33 AM
> To: 'ext Paul Kyzivat'; Jonathan = Rosenberg=20
> Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
> My=20 comments are in line.
> > -----Original Message-----=20
> >=20 From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com<= /FONT>=20
<mailto:pkyzivat@cisco.com> ]=20
> >=20 Sent: Friday, October 05, 2001 8:04 AM
> > To: Jonathan = Rosenberg=20
> > Cc:=20 Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com=20
> >=20 Subject: Re: [Simple] 200 vs. 202
> >
> >
> Seems you are both saying the same = thing. I=20 seem to recall an earlier
> dialogue where it was stated that = non-Invite=20 requests are treated
> differently than Invites in that = only one=20 response in sent back to the
> "Subscriber" in this case.  = So it would=20 appear that the PA (with proxy
> capabilities) will wait some = predetermined=20 amount of time to collect
> all of the responses (or until all = are=20 received whichever comes first)
> and send back the best response. = If the best=20 is a 202, then does the
> proxy wait for the Notify and send = the=20 202+Notify or just the 202 and
> the Notify later? I guess I don't = see the=20 need for a 202 indicating
> pending followed immediately by = another=20 message (Notify with no real
> status) which adds no value.=20
>=20
>=20
>=20
>=20 _______________________________________________ =
> simple mailing list =
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
<http://mailman.dynamicsoft.com/mailman/listinfo/simple> =20
>=20 =

------_=_NextPart_001_01C16304.A1446E40-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 16:26:30 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00963 for ; Thu, 1 Nov 2001 16:26:22 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1LN0b7029969; Thu, 1 Nov 2001 16:23:00 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18122; Thu, 1 Nov 2001 16:24:06 -0500 (EST) 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 NAA17402 for ; Thu, 1 Nov 2001 13:41:09 -0500 (EST) 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 MAA05299 for ; Thu, 1 Nov 2001 12:40:51 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 1 Nov 2001 12:34:00 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 12:40:04 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EA70851@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Moran Tim (NET/Dallas)" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , James Undery , "'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_01C16304.A1446E40" 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: Thu, 1 Nov 2001 12:40:07 -0600 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_01C16304.A1446E40 Content-Type: text/plain; charset="iso-8859-1" Forking interactions, for one. The NOTIFY is used to clear out the subscriptions that may have been created on nodes that the SUBSCRIBE got forked to, but whose response was not forwarded back to the UAC that sent the original SUBSCRIBE. 202 Pending means you've been authenticated, but not authorized yet. You can't send back a dummy (meaning a NOTIFY containing a message body) back, because that's how you signal to the subscriber that their subscription has been authorized finally (authorization triggers a NOTIFY with a message body). Thus, sending a NOTIFY back that is empty takes care of the 3-way handshake requirement, but doesn't trick the user into thinking that a subscription was authorized when it wasn't. You way basically causes the client to ping the network incessantly asking if their subscription has been authorized yet: "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?".... Seems wasteful, given that you can simply send back an empty NOTIFY, and be done with it. Your solution also does not take care of cleaning up forking interactions if I understand it correctly. The three-way handshake is in the events draft, and it works. The only issue that I can see are getting the presence and watcherinfo drafts on board with what the events draft has set forth, and just clarifying the text in the events draft a little. It's not a big change in my view. Regards, Brian -----Original Message----- From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com] Sent: Thursday, November 01, 2001 11:36 AM To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 To me the term Pending (as in 202 Pending) says hold on I can not answer right now. Sorry, but I just don't see the justification in the immediate dummy message to the receiver of the 202. I understand (think I do) that the empty Notify request is sent so that the notifier can know that the 202 was received because it causes a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake. It would appear the assumption is that 3-way handshake is required. What is wrong with the subscriber timing out on receiving a response from the notifer (200 or 202) and resending the subscribe? That is, what is wrong with a two-way handshake with a timer? Tim M. -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 10:49 AM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. Thoughts? Regards, Brian Stucker -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, November 01, 2001 10:27 AM To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. How do we reconcile this conflict? -- Dai -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, October 09, 2001 2:27 PM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 Maybe the confusion that we're having is centered around how to deal with an empty NOTIFY. If you think of an empty NOTIFY as signifying nothing about the status of the subscription (pending or accepted) and nothing about the state of the resource the subscription is made to (in this case the presence agent), then things get a lot simpler. If you think about it that way, then the processing of an empty NOTIFY creates a three-way handshake to the subscription request, and that helps with forking issues. If the events draft is updated to clarify this thinking (assuming that this is the behaviour desired), and the presence draft is updated such that an *empty* NOTIFY, and not one with bogus information in it, is sent after a 202, then I think things will get a lot less fuzzy. Jonathan? Adam? Brian -----Original Message----- From: Ngo, Dai (c) [ mailto:c-Dai.Ngo@WCOM.Com ] Sent: Tuesday, October 09, 2001 8:32 AM To: 'Brazier Lachlan'; Stucker, Brian [NGB:B621:EXCH]; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 In section 5.2.3 "Notifier NOTIFY Behavior" of draft-ietf-sip-events-00.txt from Adam Roach, it states, "When a SUBSCRIBE request is successfully processed or a relevant change in the subscribed state occurs, the notifier will construct and send a NOTIFY request to the subscribers, as specified in the contact field of the SUBSCRIBE request. Such a message should be sent in as timely a manner as is practical". In section 5.8 "Notifier Generation of NOTIFY Requests" of draft-ietf-simple-presence-03.txt it states, "If a subscription is accepted (or politely blocked) a NOTIFY must be sent after the 200 OK response to the SUBSCRIBE has been sent. Notifications MAY be sent at later times, possibly when the presence state of the presentity changes." It makes more sense to NOT sending the empty NOTIFY after a 202. Regards, -- Dai Ngo -----Original Message----- From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ] Sent: Tuesday, October 09, 2001 3:29 AM To: 'Brian Stucker'; Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: AW: [Simple] 200 vs. 202 Hello, When a subscriber receives a 200 on a SUBSCRIBE request, a NOTIFY from the presentity can be handled. NOTIFY's from other senders will be responded to with an error (481). The tags in the FROM header of these NOTIFY's are different than the tag in the To header in the response to the SUBSCRIBE. When a subscriber receives a 202 on a SUBSCRIBE request, a NOTIFY from the presentity can be handled. NOTIFY's from other senders will be responded to with an error (481). The tags in the FROM header of these NOTIFY's are different than the tag in the To header in the response to the SUBSCRIBE. The question is now, when is the presentity sending the NOTIFY? If a 200 Ok was returned to the SUBSCRIBE request, the PA of the presentity knows the status of the presentity. If a 202 Accepted was returned, it doesn't know right now, but it can find out. I believe that a NOTIFY must be sent "immediately" after sending a 2xx response to the subscriber. What does "immediately mean"? Does it mean sending the NOTIFY without delay, or does it mean sending the NOTIFY when the status is obtained by the PA? If "immediately" means after obtaining the status, I don't see the problem. If "immediately" means without delay, the first NOTIFY after sending a 202 will be useless. I've looked in the presence draft (draft-ietf-simple-presence-03.txt), but I haven't found the phrase stating, that a NOTIFY MUST be sent immediately after sending a 202 Acepted. I only found it for 200 Ok. Still, as 202 Accepted is a positive response, the NOTIFY could be required. This leads to my next question: Why is it required? Anyway, to follow the requirements, I always can send an empty NOTIFY. Please correct me, when I stated something wrong or missunderstood something! Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] Gesendet am: Dienstag, 09. Oktober 2001 01:34 An: Moran Tim (NET/Dallas); adam.roach; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Betreff: RE: [Simple] 200 vs. 202 It is my understanding that if the 200 OK is dropped to a SUBSCRIBE, the watcher must reject the subsequent NOTIFY because it never saw what the TO tag was from the response to the SUBSCRIBE (because it was in the 200 OK). You could argue that the watcher takes the TO tag in the first response or NOTIFY it gets back (as long as the FROM tag and everything else matches ok). However, that seems to be a bit dangerous if we consider cases where multiple packets are being dropped (unintentionally or otherwise). Forking subscriptions seems to be problematic at best unless you ACK the response (as Adam pointed out with the 3-way handshake mention) like an INVITE does instead of relying on a NOTIFY that does nothing because CPIM wants it. It's coming from the wrong endpoint, as you say. I would think that anything that forks, and creates a meta-session routing requirement needs to be ACK'd. Brian Stucker -----Original Message----- From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com < mailto:Tim.Moran@nokia.com > ] Sent: Monday, October 08, 2001 6:17 PM To: adam.roach; Stucker, Brian [NGB:B621:EXCH]; James Undery; Ngo, Dai (c); 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 Three-way handshake in my dictionary implies A->B, A<-B, and then a A->B again. This is not the case in a Subscribe, 200/202 and then a Notify in the same direction as the 2xx.. I am also puzzled by your "immediate" requirement after a 202 since your own draft uses phrases like ... A 202 response indicates that there may be a sizable delay before a notification is received, pending the actual creation of the subscription If the notifier owner is interactively queried to determine whether a subscription is allowed, a "202 Accept" response is returned immediately, and the subsequent NOTIFY request is suppressed until the notifier owner responds. Does the requirement for an immediate notify after a 202 only apply to forked requests? How does the server know when a request has been forked? So let's say a Subscribe is forked and all the PAs respond with 202. The best one is returned to the watcher and the rest dropped. All of the PAs must also respond with a Notify with useless information which the proxy passes on. How enlightened is the watcher upon receiving the dummy Notifications? What change is there in the state machine? Then there is the scenario of 202s come back, proxy timer expires so the best 202 is sent back to watcher - and then a 200 comes. I presume it would be dropped. The PA which sent the 200 sends a Notify (immediately) which is forwarded but there is no preceding 200 so the watcher drops it? There is the out-of-sequence clause, but if the 200 never appears wouldn't the notify be rejected? Nodes which know they can't authorize at the time of subscription may respond quicker than the node which is actually doing the work of obtaining authorization. Sounds like some guidelines are needed as to how fast is immediate and how long a proxy waits for that 200 with the immediate notify. Tim M. > -----Original Message----- > From: ext adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com < mailto:adam.roach@ericsson.com > ] > Sent: Monday, October 08, 2001 2:12 PM > To: 'Brian Stucker'; James Undery; Ngo, Dai (c); Moran Tim > (NET/Dallas); > 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > Sorry; I haven't been following this closely (things have been > hellishly busy recently). This conversation, though, seems to > have taken a dangerous turn. > > Remember that the behaviour of SUB/NOT is general, and not just > related to presence. And, in the general case, forking of SUBSCRIBEs > can be extremely useful. > > However, without a three-way handshake, such forking becomes quite > messy and unpleasant to implement. > > The immediate NOTIFY is the third message of this three-way handshake. > It can't be removed from the base SUB/NOT draft; by extension, the use > of SUB/NOT for presence needs to keep it. > > /a > > > -----Original Message----- > From: Brian Stucker [ mailto:bstucker@nortelnetworks.com < mailto:bstucker@nortelnetworks.com > ] > Sent: Monday, October 08, 2001 1:54 PM > To: James Undery; Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; > 'ext Paul Kyzivat'; > Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > Ok, as a compromise, since we all seem to feel that the > NOTIFY after a 202 is > totally useless... > Can't we make the 202 act as an implied 'Offline' (or some > other harmless, and > meaningless indication) > NOTIFY within the context of how CPIM requirements work in a > SIP network? > Gateway functions to other > protocols can generate whatever messages they want from this, > but in the > context of what gets sent > around in a SIP network, the 202 acts as a NOTIFY itself. > Heck, you could even put dummy XML in the 202 message body if > you really wanted > (but I'd rather not). > Brian Stucker > -----Original Message----- > From: James Undery [ mailto:jundery@ubiquity.net < mailto:jundery@ubiquity.net > ] > Sent: Monday, October 08, 2001 5:12 AM > To: Ngo, Dai (c); 'Moran Tim (NET/Dallas)'; 'ext Paul > Kyzivat'; Jonathan > Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > I'd like to agree with you too, unfortunately it's a CPIM requirement > as 2xx are successful responses. The SIMPLE charter requires CPIM > complience. > James > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [ mailto:simple-admin@mailman.dynamicsoft.com < mailto:simple-admin@mailman.dynamicsoft.com > ]On Behalf Of Ngo, Dai (c) > Sent: 05 October 2001 17:52 > To: 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 200 vs. 202 > > > I agree that there is no need to send an immediate, empty NOTIFY after > a 202 was sent in the pending case. > -- Dai > -----Original Message----- > From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com < mailto:Tim.Moran@nokia.com > ] > Sent: Friday, October 05, 2001 10:33 AM > To: 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] 200 vs. 202 > My comments are in line. > > -----Original Message----- > > From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com < mailto:pkyzivat@cisco.com > ] > > Sent: Friday, October 05, 2001 8:04 AM > > To: Jonathan Rosenberg > > Cc: Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] 200 vs. 202 > > > > > Seems you are both saying the same thing. I seem to recall an earlier > dialogue where it was stated that non-Invite requests are treated > differently than Invites in that only one response in sent back to the > "Subscriber" in this case. So it would appear that the PA (with proxy > capabilities) will wait some predetermined amount of time to collect > all of the responses (or until all are received whichever comes first) > and send back the best response. If the best is a 202, then does the > proxy wait for the Notify and send the 202+Notify or just the 202 and > the Notify later? I guess I don't see the need for a 202 indicating > pending followed immediately by another message (Notify with no real > status) which adds no value. > > > > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinfo/simple < http://mailman.dynamicsoft.com/mailman/listinfo/simple > > ------_=_NextPart_001_01C16304.A1446E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202
Forking interactions, for one. The NOTIFY is used to clear out = the=20 subscriptions that may have been created on nodes that the SUBSCRIBE = got forked=20 to, but whose response was not forwarded back to the UAC that sent the = original=20 SUBSCRIBE.
 
202=20 Pending means you've been authenticated, but not authorized yet. You = can't send=20 back a dummy (meaning a NOTIFY containing a message body) back, because = that's=20 how you signal to the subscriber that their subscription has been = authorized=20 finally (authorization triggers a NOTIFY with a message body). Thus, = sending a=20 NOTIFY back that is empty takes care of the 3-way handshake = requirement, but=20 doesn't trick the user into thinking that a subscription was authorized = when it=20 wasn't.
 
You=20 way basically causes the client to ping the network incessantly asking = if their=20 subscription has been authorized yet: "Am I authorized yet?", "Am I = authorized=20 yet?", "Am I authorized yet?", "Am I authorized yet?".... Seems = wasteful, given=20 that you can simply send back an empty NOTIFY, and be done with it. = Your=20 solution also does not take care of cleaning up forking interactions if = I=20 understand it correctly.
 
The=20 three-way handshake is in the events draft, and it works. The only = issue that I=20 can see are getting the presence and watcherinfo drafts on board with = what the=20 events draft has set forth, and just clarifying the text in the events = draft a=20 little. It's not a big change in my view.
 
Regards,
 
Brian
-----Original Message-----
From: Moran Tim = (NET/Dallas)=20 [mailto:Tim.Moran@nokia.com]
Sent: Thursday, November 01, = 2001 11:36=20 AM
To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); = 'Brazier=20 Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

To=20 me the term Pending (as in 202 Pending) says hold on I can not = answer=20 right now. Sorry, but I just don't see the justification in the = immediate=20 dummy message to the receiver of the 202. I understand (think I do) = that the=20 empty Notify request is sent so that the notifier can know that the = 202 was=20 received because it causes a 200 from Subscriber to Notifier. 4 = messages to do=20 a 3 way handshake.
 
It=20 would appear the assumption is that 3-way handshake is required.=20 What is wrong with the subscriber timing out on receiving a = response=20 from the notifer (200 or 202) and resending the subscribe? That is, = what is=20 wrong with a  two-way handshake with a = timer?
 
Tim=20 M.
-----Original Message-----
From: ext Brian = Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, = November 01,=20 2001 10:49 AM
To: Ngo, Dai (c); 'Brazier Lachlan'; Moran = Tim=20 (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; = Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

The wording there can be taken several ways, and probably = needs to be=20 clarified. We really need to be talking about two notifications at = the point=20 at which a pending subscription comes in: notifying the client that = has a=20 event-package.winfo subscription, and notifying the client that is=20 requesting the new event-package subscription (where in this case,=20 event-package is likely to be "presence").
 
I=20 would argue that you should send an empty NOTIFY to the "presence"=20 subscription, and send a NOTIFY to the "presence.winfo" subscriber = telling=20 them that the subscription is waiting for their authorization. If = the=20 subscription is a refresh of the pending "presence" subscription, = then you=20 need to send an empty NOTIFY to the "presence" subscription, but = it's a=20 MAY notify on the "presence.winfo" side (the = renotification may=20 not be particularly useful).
 
 
I=20 think the new version of the events draft is supposed to be sent = out today,=20 so maybe that'll provide more clarification.
 
Thoughts?
 
Regards,
 
Brian Stucker
-----Original Message-----
From: Ngo, Dai (c)=20 [mailto:c-Dai.Ngo@WCOM.Com]
Sent: Thursday, November = 01, 2001=20 10:27 AM
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier = Lachlan';=20 Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul = Kyzivat';=20 Jonathan Rosenberg
Cc: simple
Subject: RE: = [Simple]=20 200 vs. 202

While = reviewing=20 the draft "draft-ietf-simple-winfo-package-00.txt" in the section = 3.6.1=20 "The Watcherinfo State Machine" it says, "If, when a subscription = arrives,=20 there is no authorization policy in existence, the subscription = moves into=20 the pending state. In this state, the server is awaiting an = authorization=20 decision. *No notifications = are=20 generated*, but the subscription FSM is=20 maintained."

It = seems to me=20 that the above statement contradicts with what we are saying = here, that an=20 empty notification is needed to complete the three-ways=20 handshake.

 

How do = we=20 reconcile this conflict?

 

--=20 Dai

 

 

 

-----Original=20 Message-----
From: Brian=20 Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Tuesday, October 09, = 2001 2:27=20 PM
To: Ngo, = Dai (c);=20 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James = Undery; 'ext=20 Paul Kyzivat'; Jonathan Rosenberg
Cc: simple
Subject: RE: [Simple] 200 = vs.=20 202

 

Maybe=20 the confusion that we're having is centered around how to deal = with=20 an
empty=20 NOTIFY. If you think of an empty NOTIFY as signifying nothing = about=20 the
status of=20 the subscription (pending or accepted) and nothing about the=20 state
of the=20 resource the subscription is made to (in this case the presence=20 agent),
then=20 things get a lot simpler.

If=20 you think about it that way, then the processing of an empty = NOTIFY=20 creates
a=20 three-way handshake to the subscription request, and that helps = with=20 forking
issues.

If=20 the events draft is updated to clarify this thinking (assuming = that this=20 is
the=20 behaviour desired), and the presence draft is updated such that = an=20 *empty*
NOTIFY, and not one with bogus = information in it,=20 is sent after a 202, then I
think things will get a lot less=20 fuzzy.

Jonathan? Adam? =

Brian

-----Original = Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]= =20
Sent: Tuesday, = October 09,=20 2001 8:32 AM
To: 'Brazier Lachlan'; Stucker, Brian=20 [NGB:B621:EXCH]; Moran Tim
(NET/Dallas); adam.roach; James Undery; = 'ext Paul=20 Kyzivat'; Jonathan
Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. = 202=20

 

In=20 section 5.2.3 "Notifier NOTIFY Behavior" of=20 draft-ietf-sip-events-00.txt
from Adam Roach, it states, "When a = SUBSCRIBE=20 request is successfully
processed or a relevant change in the = subscribed=20 state occurs, the notifier
will construct and send a NOTIFY = request to the=20 subscribers, as specified in
the contact field of the SUBSCRIBE = request. Such a=20 message should be sent in
as timely a manner as is = practical".=20

In=20 section 5.8 "Notifier Generation of NOTIFY Requests" = of=20
draft-ietf-simple-presence-03.txt it = states, "If a=20 subscription is accepted
(or politely blocked) a NOTIFY must be = sent after=20 the 200 OK response to the
SUBSCRIBE has been sent. Notifications = MAY be sent=20 at later times, possibly
when the presence state of the = presentity=20 changes."

It=20 makes more sense to NOT sending the empty NOTIFY after a=20 202.

Regards,

--=20 Dai Ngo

-----Original = Message-----
From: Brazier Lachlan = [mailto:lachlan.brazier@= siemens.at]=20
Sent:=20 Tuesday, October 09, 2001 3:29 AM
To: 'Brian Stucker'; Moran Tim = (NET/Dallas);=20 adam.roach; James Undery; Ngo,
Dai (c); 'ext Paul Kyzivat'; Jonathan=20 Rosenberg
Cc:=20 simple
Subject: AW: [Simple] 200 vs. = 202=20

Hello,
 
When a subscriber receives a 200 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's = from other=20 senders will be responded to
with an error (481). The tags in the = FROM header=20 of these NOTIFY's are
different than the tag in the To header = in the=20 response to the SUBSCRIBE.
 
When a subscriber receives a 202 on a = SUBSCRIBE=20 request, a NOTIFY from the
presentity can be handled. NOTIFY's = from other=20 senders will be responded to
with an error (481). The tags in the = FROM header=20 of these NOTIFY's are
different than the tag in the To header = in the=20 response to the SUBSCRIBE.
 
 
The question is now, when is the = presentity=20 sending the NOTIFY?
 
If a 200 Ok was returned to the = SUBSCRIBE request,=20 the PA of the presentity
knows the status of the presentity. If = a 202=20 Accepted was returned, it
doesn't know right now, but it can find = out.
 
I believe that a NOTIFY must be sent = "immediately"=20 after sending a 2xx
response to the subscriber. What does = "immediately=20 mean"? Does it mean
sending the NOTIFY without delay, or = does it mean=20 sending the NOTIFY when
the status is obtained by the = PA?=20
 =20
If = "immediately" means=20 after obtaining the status, I don't see the = problem.=20
 =20
If = "immediately" means=20 without delay, the first NOTIFY after sending a 202 =
will be = useless. I've=20 looked in the presence draft
(draft-ietf-simple-presence-03.txt), = but I haven't=20 found the phrase stating,
that a NOTIFY MUST be sent immediately = after=20 sending a 202 Acepted. I only
found it for 200 Ok. =
Still, as 202 Accepted = is a positive=20 response, the NOTIFY could be required. =

This=20 leads to my next question: Why is it required? =
Anyway, to follow the = requirements, I=20 always can send an empty NOTIFY.
 
 
Please correct me, when I stated = something wrong=20 or missunderstood
something!
 
Lachlan
 
 

-----Urspr=FCngliche = Nachricht-----=20
Von: Brian = Stucker [mailto:bstucker@nortelnetwor= ks.com]=20
Gesendet am: = Dienstag, 09.=20 Oktober 2001 01:34
An: Moran Tim (NET/Dallas); adam.roach; = James=20 Undery; Ngo, Dai (c); 'ext
Paul Kyzivat'; Jonathan = Rosenberg=20
Cc: = simple=20
Betreff: RE: = [Simple] 200=20 vs. 202

 

It is=20 my understanding that if the 200 OK is dropped to a SUBSCRIBE,=20 the
watcher=20 must reject the subsequent NOTIFY because it never saw what the=20 TO
tag was=20 from the response to the SUBSCRIBE (because it was in the 200=20 OK).
You=20 could argue that the watcher takes the TO tag in the first = response=20 or
NOTIFY it=20 gets back (as long as the FROM tag and everything else=20 matches
ok).=20 However, that seems to be a bit dangerous if we consider cases=20 where
multiple packets are being dropped=20 (unintentionally or otherwise).

Forking subscriptions seems to be = problematic at=20 best unless you ACK the
response (as Adam pointed out with the = 3-way=20 handshake mention) like an
INVITE does instead of relying on a = NOTIFY that=20 does nothing because CPIM
wants it. It's coming from the wrong = endpoint, as=20 you say. I would think
that anything that forks, and creates a = meta-session routing requirement
needs to be ACK'd. =

Brian=20 Stucker

 

-----Original Message----- =
From: Moran Tim = (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20
<mailto:Tim.Moran@nokia.com> = ]=20
Sent: Monday,=20 October 08, 2001 6:17 PM
To: adam.roach; Stucker, Brian = [NGB:B621:EXCH];=20 James Undery; Ngo, Dai (c);
'ext Paul Kyzivat'; Jonathan Rosenberg=20
Cc: simple=20
Subject: RE:=20 [Simple] 200 vs. 202

 

Three-way handshake in my dictionary = implies=20 A->B, A<-B, and then a A->B
again. This is not the case in a = Subscribe,=20 200/202 and then a Notify in
the same direction as the 2xx.. I am = also puzzled=20 by your "immediate"
requirement after a 202 since your own = draft uses=20 phrases like ...

A 202=20 response indicates that there may be a sizable delay before=20 a
notification is received, pending the = actual=20 creation of the subscription

If=20 the notifier owner is interactively queried to determine whether=20 a
subscription is allowed, a "202 Accept" = response=20 is returned immediately,
and the subsequent NOTIFY request is = suppressed=20 until the notifier  owner
responds.

Does=20 the requirement for an immediate notify after a 202 only apply=20 to
forked=20 requests? How does the server know when a request has been=20 forked?

So=20 let's say a Subscribe is forked and all the PAs respond with 202. = The
best one=20 is returned to the watcher and the rest dropped. All of the=20 PAs
must also=20 respond with a Notify with useless information which the=20 proxy
passes=20 on. How enlightened is the watcher upon receiving the = dummy=20
Notifications? = What change=20 is there in the state machine? Then there is the =
scenario of 202s come = back, proxy=20 timer expires so the best 202 is sent back =
to watcher - and then a = 200 comes. I=20 presume it would be dropped. The PA
which sent the 200 sends a Notify = (immediately)=20 which is forwarded but there
is no preceding 200 so the watcher = drops it? =20 There is the out-of-sequence
clause, but if the 200 never appears = wouldn't the=20 notify be rejected? Nodes
which know they can't authorize at the = time of=20 subscription may respond
quicker than the node which is actually = doing the=20 work of obtaining
authorization. Sounds like some = guidelines are=20 needed as to how fast is
immediate and how long a proxy waits = for that 200=20 with the immediate notify.

Tim=20 M.

>=20 -----Original Message-----
> From: ext adam.roach@ericsson.com = [ mailto:adam.roach@ericsson.com=20
<mailto:adam.roach@ericsson.com>=20 ]
> Sent:=20 Monday, October 08, 2001 2:12 PM
> To: 'Brian Stucker'; James Undery; = Ngo, Dai=20 (c); Moran Tim
> (NET/Dallas); =
> 'ext Paul Kyzivat'; = Jonathan=20 Rosenberg
> Cc: simple
> Subject: RE: = [Simple] 200 vs.=20 202
>=20
>=20
> Sorry; I=20 haven't been following this closely (things have been=20
>=20 hellishly busy recently). This conversation, though, seems to=20
> have=20 taken a dangerous turn.
>
> Remember that the behaviour of = SUB/NOT is=20 general, and not just
> related to presence. And, in the = general=20 case, forking of SUBSCRIBEs
> can be extremely useful.=20
>=20
> However,=20 without a three-way handshake, such forking becomes quite=20
> messy=20 and unpleasant to implement.
>
> The immediate NOTIFY is the third = message of=20 this three-way handshake.
> It can't be removed from the base = SUB/NOT=20 draft; by extension, the use
> of SUB/NOT for presence needs to = keep it.=20
>=20
> /a=20
>=20
>=20
>=20 -----Original Message-----
> From: Brian Stucker [ mailto:bstucker@nortelnetwor= ks.com=20
<mailto:bstucker@nortelnetwor= ks.com>=20 ]
> Sent:=20 Monday, October 08, 2001 1:54 PM
> To: James Undery; Ngo, Dai (c); = 'Moran Tim=20 (NET/Dallas)';
> 'ext Paul Kyzivat'; =
> Jonathan Rosenberg=20
> Cc:=20 simple
>=20 Subject: RE: [Simple] 200 vs. 202
>
>
> Ok, as a compromise, since we all = seem to=20 feel that the
> NOTIFY after a 202 is =
> totally useless...=20
> Can't we=20 make the 202 act as an implied 'Offline' (or some =
> other harmless, and =
>=20 meaningless indication)
> NOTIFY within the context of how = CPIM=20 requirements work in a
> SIP network? =
> Gateway functions = to other=20
>=20 protocols can generate whatever messages they want from this,=20
> but in=20 the
>=20 context of what gets sent
> around in a SIP network, the 202 = acts as a=20 NOTIFY itself.
> Heck, you could even put dummy XML = in the 202=20 message body if
> you really wanted =
> (but I'd rather = not).=20
> Brian=20 Stucker
>=20 -----Original Message-----
> From: James Undery [ mailto:jundery@ubiquity.net=20
<mailto:jundery@ubiquity.net>= ]=20
> Sent:=20 Monday, October 08, 2001 5:12 AM
> To: Ngo, Dai (c); 'Moran Tim = (NET/Dallas)';=20 'ext Paul
> Kyzivat'; Jonathan =
> Rosenberg=20
> Cc:=20 simple
>=20 Subject: RE: [Simple] 200 vs. 202
>
>
> I'd like to agree with you too, = unfortunately=20 it's a CPIM requirement
> as 2xx are successful responses. = The SIMPLE=20 charter requires CPIM
> complience. =
> James =
> -----Original = Message-----=20
> From:=20 simple-admin@mailman.dynamicsoft.com
> [ mailto:simple-admin= @mailman.dynamicsoft.com=20
<mailto:simple-admin= @mailman.dynamicsoft.com>=20 ]On Behalf Of Ngo, Dai (c)
> Sent: 05 October 2001 17:52=20
> To:=20 'Moran Tim (NET/Dallas)'; 'ext Paul Kyzivat'; Jonathan Rosenberg=20
> Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
>=20
>=20
> I agree=20 that there is no need to send an immediate, empty NOTIFY after=20
> a 202=20 was sent in the pending case.
> -- Dai
> -----Original Message-----=20
> From:=20 Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com=20
<mailto:Tim.Moran@nokia.com> = ]=20
> Sent:=20 Friday, October 05, 2001 10:33 AM
> To: 'ext Paul Kyzivat'; Jonathan = Rosenberg=20
> Cc:=20 simple@mailman.dynamicsoft.com
> Subject: RE: [Simple] 200 vs. 202=20
> My=20 comments are in line.
> > -----Original Message-----=20
> >=20 From: ext Paul Kyzivat [ mailto:pkyzivat@cisco.com<= /FONT>=20
<mailto:pkyzivat@cisco.com> ]=20
> >=20 Sent: Friday, October 05, 2001 8:04 AM
> > To: Jonathan = Rosenberg=20
> > Cc:=20 Moran Tim (NET/Dallas); simple@mailman.dynamicsoft.com=20
> >=20 Subject: Re: [Simple] 200 vs. 202
> >
> >
> Seems you are both saying the same = thing. I=20 seem to recall an earlier
> dialogue where it was stated that = non-Invite=20 requests are treated
> differently than Invites in that = only one=20 response in sent back to the
> "Subscriber" in this case.  = So it would=20 appear that the PA (with proxy
> capabilities) will wait some = predetermined=20 amount of time to collect
> all of the responses (or until all = are=20 received whichever comes first)
> and send back the best response. = If the best=20 is a 202, then does the
> proxy wait for the Notify and send = the=20 202+Notify or just the 202 and
> the Notify later? I guess I don't = see the=20 need for a 202 indicating
> pending followed immediately by = another=20 message (Notify with no real
> status) which adds no value.=20
>=20
>=20
>=20
>=20 _______________________________________________ =
> simple mailing list =
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinfo/simple=20
<http://mailman.dynamicsoft.com/mailman/listinfo/simple> =20
>=20 =

------_=_NextPart_001_01C16304.A1446E40-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 16:27:06 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00987 for ; Thu, 1 Nov 2001 16:26:52 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA1LO6b7029995; Thu, 1 Nov 2001 16:24:06 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18184; Thu, 1 Nov 2001 16:25:36 -0500 (EST) 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 NAA17516 for ; Thu, 1 Nov 2001 13:53:22 -0500 (EST) 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 MAA11031 for ; Thu, 1 Nov 2001 12:53:05 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 1 Nov 2001 12:46:01 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Nov 2001 12:52:06 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EA70878@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , "Moran Tim (NET/Dallas)" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , James Undery , "'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_01C16306.4F63AAD0" 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: Thu, 1 Nov 2001 12:52:09 -0600 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_01C16306.4F63AAD0 Content-Type: text/plain; charset="iso-8859-1" Forking interactions, for one. The NOTIFY is used to clear out the subscriptions that may have been created on nodes that the SUBSCRIBE got forked to, but whose response was not forwarded back to the UAC that sent the original SUBSCRIBE. 202 Pending means you've been authenticated, but not authorized yet. You can't send back a dummy (meaning a NOTIFY containing a message body) back, because that's how you signal to the subscriber that their subscription has been authorized finally (authorization triggers a NOTIFY with a message body). Thus, sending a NOTIFY back that is empty takes care of the 3-way handshake requirement, but doesn't trick the user into thinking that a subscription was authorized when it wasn't. You way basically causes the client to ping the network incessantly asking if their subscription has been authorized yet: "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?".... Seems wasteful, given that you can simply send back an empty NOTIFY, and be done with it. Your solution also does not take care of cleaning up forking interactions if I understand it correctly. The three-way handshake is in the events draft, and it works. The only issue that I can see are getting the presence and watcherinfo drafts on board with what the events draft has set forth, and just clarifying the text in the events draft a little. It's not a big change in my view. Regards, Brian -----Original Message----- From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com] Sent: Thursday, November 01, 2001 11:36 AM To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 To me the term Pending (as in 202 Pending) says hold on I can not answer right now. Sorry, but I just don't see the justification in the immediate dummy message to the receiver of the 202. I understand (think I do) that the empty Notify request is sent so that the notifier can know that the 202 was received because it causes a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake. It would appear the assumption is that 3-way handshake is required. What is wrong with the subscriber timing out on receiving a response from the notifer (200 or 202) and resending the subscribe? That is, what is wrong with a two-way handshake with a timer? Tim M. -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 10:49 AM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. Thoughts? Regards, Brian Stucker -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, November 01, 2001 10:27 AM To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. How do we reconcile this conflict? -- Dai ------_=_NextPart_001_01C16306.4F63AAD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Forking interactions, for one. The NOTIFY is used to = clear out the subscriptions that may have been created on nodes that = the SUBSCRIBE got forked to, but whose response was not forwarded back = to the UAC that sent the original SUBSCRIBE.

202 Pending means you've been authenticated, but not = authorized yet. You can't send back a dummy (meaning a NOTIFY = containing a message body) back, because that's how you signal to the = subscriber that their subscription has been authorized finally = (authorization triggers a NOTIFY with a message body). Thus, sending a = NOTIFY back that is empty takes care of the 3-way handshake = requirement, but doesn't trick the user into thinking that a = subscription was authorized when it wasn't.

You way basically causes the client to ping the = network incessantly asking if their subscription has been authorized = yet: "Am I authorized yet?", "Am I authorized = yet?", "Am I authorized yet?", "Am I authorized = yet?".... Seems wasteful, given that you can simply send back an = empty NOTIFY, and be done with it. Your solution also does not take = care of cleaning up forking interactions if I understand it = correctly.

The three-way handshake is in the events draft, and = it works. The only issue that I can see are getting the presence and = watcherinfo drafts on board with what the events draft has set forth, = and just clarifying the text in the events draft a little. It's not a = big change in my view.

Regards,

Brian
-----Original Message-----
From: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com]
Sent: Thursday, November 01, 2001 11:36 AM
To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); = 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; = Jonathan Rosenberg

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


To me the term Pending (as in 202 Pending) says hold = on I can not answer right now. Sorry, but I just don't see the = justification in the immediate dummy message to the receiver of the = 202. I understand (think I do) that the empty Notify request is sent so = that the notifier can know that the 202 was received because it causes = a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake. =

It would appear the assumption is that 3-way = handshake is required. What is wrong with the subscriber timing out on = receiving a response from the notifer (200 or 202) and resending the = subscribe? That is, what is wrong with a  two-way handshake with a = timer?

Tim M.
-----Original Message-----
From: ext Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Thursday, November 01, 2001 10:49 AM
To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim = (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan = Rosenberg

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


The wording there can be taken several ways, and = probably needs to be clarified. We really need to be talking about two = notifications at the point at which a pending subscription comes in: = notifying the client that has a event-package.winfo subscription, and = notifying the client that is requesting the new event-package = subscription (where in this case, event-package is likely to be = "presence").

I would argue that you should send an empty NOTIFY to = the "presence" subscription, and send a NOTIFY to the = "presence.winfo" subscriber telling them that the = subscription is waiting for their authorization. If the subscription is = a refresh of the pending "presence" subscription, then you = need to send an empty NOTIFY to the "presence" subscription, = but it's a MAY notify on the "presence.winfo" side (the = renotification may not be particularly useful).


I think the new version of the events draft is = supposed to be sent out today, so maybe that'll provide more = clarification.

Thoughts?

Regards,

Brian Stucker
-----Original Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com]=
Sent: Thursday, November 01, 2001 10:27 AM
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier = Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul = Kyzivat'; Jonathan Rosenberg

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


While reviewing the draft = "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 = "The Watcherinfo State Machine" it says, "If, when a = subscription arrives, there is no authorization policy in existence, = the subscription moves into the pending state. In this state, the = server is awaiting an authorization decision. *No notifications are = generated*, but the subscription FSM is maintained."

It seems to me that the above statement contradicts = with what we are saying here, that an empty notification is needed to = complete the three-ways handshake.

 
How do we reconcile this conflict?
 
-- Dai
 
 
 

------_=_NextPart_001_01C16306.4F63AAD0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 1 19:14:05 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03254 for ; Thu, 1 Nov 2001 19:14:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA20Bab7001276; Thu, 1 Nov 2001 19:11:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18804; Thu, 1 Nov 2001 19:13:04 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA18792 for ; Thu, 1 Nov 2001 19:12:20 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.americas.nokia.com [172.18.194.216]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA20CdA00604 for ; Fri, 2 Nov 2001 02:12:39 +0200 (EET) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fA20C5Q25771 for ; Thu, 1 Nov 2001 18:12:05 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 1 Nov 2001 18:11:59 -0600 Received: from daebe004.NOE.Nokia.com ([172.18.242.201]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 1 Nov 2001 18:11:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [Simple] 200 vs. 202 Message-ID: <278B6B0D76698D45BBA872CD23DD496A0A421E@daebe004.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16332.F768BA78" Thread-Topic: [Simple] 200 vs. 202 Thread-Index: AcFjBnHvTb7K9s7zEdWxLwAIx6TWeAADw/8Q From: "Moran Tim (NET/Dallas)" To: "'ext Brian Stucker'" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , "James Undery" , "'ext Paul Kyzivat'" , "Jonathan Rosenberg" Cc: "simple" X-OriginalArrivalTime: 02 Nov 2001 00:11:59.0418 (UTC) FILETIME=[FD69F9A0:01C16332] 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, 1 Nov 2001 18:11:49 -0600 This is a multi-part message in MIME format. ------_=_NextPart_001_01C16332.F768BA78 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 12:52 PM To: Brian Stucker; Moran Tim (NET/Dallas); Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 [Tim] I think I've reached a point where a set of flows are needed.=20 =20 Forking interactions, for one. The NOTIFY is used to clear out the subscriptions that may have been created on nodes that the SUBSCRIBE got forked to, but whose response was not forwarded back to the UAC that sent the original SUBSCRIBE. [Tim] . Section 5 of sip events does not recommend canceling subscriptions. But assuming we need to, what is wrong with the scenario of:=20 1. proxy forks subscription to multiple potential notifiers (PAs).=20 2. Some number of notifiers send 202.=20 3. Either one of the notifiers sends a 200 or if none, then at some time later a notifier sends a non-empty Notify.=20 4. Now, the proxy wishes to cancel the subscription in the other notifiers. It sends Cancel request & receives 487. The timer I refer to (in the earlier email) is for receiving a 200/202 from the notifier (not for the Notify itself). Now you might ask the question of how does the forking proxy know when to cancel the subscription if none of the notifiers sent a 200 or non-empty notify in short order? Well, I think the forking proxy would need to set some larger granularity timer to cancel the subscription. At that time it could send the Cancel Request or not worry about the Notifier state and let it handle its own gross time cleanup. If all the 202 notifiers send an empty Notify you still haven't bought anything in terms of state machine cleanup since you are still waiting for that "real" notify with real information. Were you thinking of doing cleanup by sending a 487 to the Notify requests of the non-forwarding notifiers??? =20 So, the way I see it is that you 1) if noone sent a 200 ensure all notifiers send 202 and if not try 1 or 2 more times and give up (a rarity) then 2) if noone sent a 200, wait for a real Notify. 3) if no real notifys are received for a reasonable amt of time, forget about it (do internal cleanup) or explicitly cancel the request with each notifier. 202 Pending means you've been authenticated, but not authorized yet. You can't send back a dummy (meaning a NOTIFY containing a message body) back, because that's how you signal to the subscriber that their subscription has been authorized finally (authorization triggers a NOTIFY with a message body). Thus, sending a NOTIFY back that is empty takes care of the 3-way handshake requirement, but doesn't trick the user into thinking that a subscription was authorized when it wasn't. [Tim] I should have been clear in that dummy notify is an empty notify.=20 You way basically causes the client to ping the network incessantly asking if their subscription has been authorized yet: "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?", "Am I authorized yet?".... Seems wasteful, given that you can simply send back an empty NOTIFY, and be done with it. Your solution also does not take care of cleaning up forking interactions if I understand it correctly. [Tim] The timer I mentioned was for the 200/202 response in case it got lost, not for the Notify. After receiving a 202 you don't ping. Again, the 202 to me means wait - I'll get back with you later - maybe as I understand from 2068 (HTTP)". Now if later gets to be ridiculous and you are running out of state variable space - cancel or just abort the subscription in the proxy - and the notifier --- and even the subscriber. The three-way handshake is in the events draft, and it works. The only issue that I can see are getting the presence and watcherinfo drafts on board with what the events draft has set forth, and just clarifying the text in the events draft a little. It's not a big change in my view. Regards,=20 Brian=20 -----Original Message-----=20 From: Moran Tim (NET/Dallas) [ mailto:Tim.Moran@nokia.com]=20 Sent: Thursday, November 01, 2001 11:36 AM=20 To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 To me the term Pending (as in 202 Pending) says hold on I can not answer right now. Sorry, but I just don't see the justification in the immediate dummy message to the receiver of the 202. I understand (think I do) that the empty Notify request is sent so that the notifier can know that the 202 was received because it causes a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake.=20 It would appear the assumption is that 3-way handshake is required. What is wrong with the subscriber timing out on receiving a response from the notifer (200 or 202) and resending the subscribe? That is, what is wrong with a two-way handshake with a timer? Tim M.=20 -----Original Message-----=20 From: ext Brian Stucker [ mailto:bstucker@nortelnetworks.com]=20 Sent: Thursday, November 01, 2001 10:49 AM=20 To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. Thoughts?=20 Regards,=20 Brian Stucker=20 -----Original Message-----=20 From: Ngo, Dai (c) [ mailto:c-Dai.Ngo@WCOM.Com]=20 Sent: Thursday, November 01, 2001 10:27 AM=20 To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple=20 Subject: RE: [Simple] 200 vs. 202=20 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. How do we reconcile this conflict?=20 =20 -- Dai=20 =20 =20 =20 ------_=_NextPart_001_01C16332.F768BA78 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202
 
-----Original Message-----
From: ext Brian Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Thursday, = November 01,=20 2001 12:52 PM
To: Brian Stucker; Moran Tim (NET/Dallas); = Ngo, Dai=20 (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; = Jonathan=20 Rosenberg
Cc: simple
Subject: RE: [Simple] 200 vs. = 202

[Tim] I think I've reached a point where = a set=20 of flows are needed. 
 
Forking=20 interactions, for one. The NOTIFY is used to clear out the = subscriptions that=20 may have been created on nodes that the SUBSCRIBE got forked to, but = whose=20 response was not forwarded back to the UAC that sent the original=20 SUBSCRIBE.
[Tim] . Section 5 of sip events does not = recommend=20 canceling subscriptions. But assuming we need to, what is wrong with = the=20 scenario of:
  1. proxy forks subscription to multiple potential = notifiers=20 (PAs).
  2. Some number of notifiers send=20 202. 
  3. Either one of the notifiers sends a 200 or if = none, then=20 at some time later a notifier sends a non-empty Notify.=20
  4. Now, the proxy wishes to cancel the subscription in = the other=20 notifiers. It sends Cancel request & receives=20 487.
The=20 timer I refer to (in the earlier email) is for receiving a = 200/202 from=20 the notifier (not for the Notify itself). Now you might ask the = question of=20 how does the forking proxy know when to cancel the subscription if = none of the=20 notifiers sent a 200 or non-empty notify in short order? Well,  I = think=20 the forking proxy would need to set some larger granularity timer to = cancel=20 the subscription. At that time it could send the Cancel Request or not = worry=20 about the Notifier state and let it handle its own gross time cleanup. = If all=20 the 202 notifiers send an empty Notify you still haven't bought = anything in=20 terms of state machine cleanup since you are still waiting for that = "real"=20 notify with real information. Were you thinking of doing cleanup by = sending a=20 487 to the Notify requests of the non-forwarding=20 notifiers???
 
So,=20 the way I see it is that you 1) if noone sent a 200 ensure all = notifiers send=20 202  and if not try 1 or 2 more times and give up (a rarity) then = 2) if=20 noone sent a 200, wait for a real Notify. 3) if no real notifys are = received=20 for a reasonable amt of time, forget about it (do internal cleanup) or = explicitly cancel the request with each notifier.

202 Pending means you've been authenticated, but not = authorized yet. You can't send back a dummy (meaning a NOTIFY = containing a=20 message body) back, because that's how you signal to the subscriber = that their=20 subscription has been authorized finally (authorization triggers a = NOTIFY with=20 a message body). Thus, sending a NOTIFY back that is empty takes care = of the=20 3-way handshake requirement, but doesn't trick the user into thinking = that a=20 subscription was authorized when it wasn't.
[Tim] I should=20 have been clear in that dummy notify is an empty=20 notify. 

You way basically causes the client to ping the = network=20 incessantly asking if their subscription has been authorized yet: "Am = I=20 authorized yet?", "Am I authorized yet?", "Am I authorized yet?", "Am = I=20 authorized yet?".... Seems wasteful, given that you can simply send = back an=20 empty NOTIFY, and be done with it. Your solution also does not take = care of=20 cleaning up forking interactions if I understand it = correctly.
[Tim] The timer I=20 mentioned was for the 200/202 response in case it got lost, not = for the Notify.  After receiving a 202 you don't ping. = Again,=20 the 202 to me means     wait - I'll get back with = you=20 later - maybe      as I understand from 2068 = (HTTP)". Now=20 if later gets to be ridiculous and you are running out of state = variable space=20 - cancel or just abort the subscription in the proxy - and the = notifier ---=20 and even the subscriber.

The three-way handshake is in the events draft, and = it works.=20 The only issue that I can see are getting the presence and watcherinfo = drafts=20 on board with what the events draft has set forth, and just clarifying = the=20 text in the events draft a little. It's not a big change in my=20 view.

Regards,

Brian
-----Original=20 Message-----
From: Moran Tim (NET/Dallas) = [mailto:Tim.Moran@nokia.com]=20
Sent: Thursday, November 01, 2001 11:36 AM =
To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier = Lachlan';=20 adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan = Rosenberg

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


To me the term Pending (as in 202 Pending) says hold = on I can=20 not answer right now. Sorry, but I just don't see the justification in = the=20 immediate dummy message to the receiver of the 202. I understand = (think I do)=20 that the empty Notify request is sent so that the notifier can know = that the=20 202 was received because it causes a 200 from Subscriber to Notifier. = 4=20 messages to do a 3 way handshake.

It would appear the assumption is that 3-way = handshake is=20 required. What is wrong with the subscriber timing out on receiving a = response=20 from the notifer (200 or 202) and resending the subscribe? That is, = what is=20 wrong with a  two-way handshake with a timer?

Tim M.
-----Original=20 Message-----
From: ext Brian Stucker [mailto:bstucker@nortelnetwork= s.com]=20
Sent: Thursday, November 01, 2001 10:49 AM =
To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas);=20 adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan = Rosenberg

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


The wording there can be taken several ways, and = probably=20 needs to be clarified. We really need to be talking about two = notifications at=20 the point at which a pending subscription comes in: notifying the = client that=20 has a event-package.winfo subscription, and notifying the client that = is=20 requesting the new event-package subscription (where in this case,=20 event-package is likely to be "presence").

I would argue that you should send an empty NOTIFY = to the=20 "presence" subscription, and send a NOTIFY to the "presence.winfo" = subscriber=20 telling them that the subscription is waiting for their authorization. = If the=20 subscription is a refresh of the pending "presence" subscription, then = you=20 need to send an empty NOTIFY to the "presence" subscription, but it's = a MAY=20 notify on the "presence.winfo" side (the renotification may not be=20 particularly useful).


I think the new version of the events draft is = supposed to be=20 sent out today, so maybe that'll provide more = clarification.

Thoughts?

Regards,

Brian Stucker
-----Original=20 Message-----
From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] =
Sent: Thursday, November 01, 2001 10:27 AM =
To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran = Tim=20 (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan=20 Rosenberg

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


While reviewing the draft=20 "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The = Watcherinfo=20 State Machine" it says, "If, when a subscription arrives, there is no=20 authorization policy in existence, the subscription moves into the = pending=20 state. In this state, the server is awaiting an authorization = decision. *No=20 notifications are generated*, but the subscription FSM is=20 maintained."

It seems to me that the above statement contradicts = with what=20 we are saying here, that an empty notification is needed to complete = the=20 three-ways handshake.


How do we reconcile this=20 conflict?
 
-- Dai=20
 
  =
 

------_=_NextPart_001_01C16332.F768BA78-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 05:01:40 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28667 for ; Fri, 2 Nov 2001 05:01:39 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA29xcb7003021; Fri, 2 Nov 2001 04:59:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20602; Fri, 2 Nov 2001 05:01:07 -0500 (EST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20591 for ; Fri, 2 Nov 2001 05:00:24 -0500 (EST) Received: from libero.it (193.70.192.63) by smtp2.libero.it (6.0.032) id 3BD43C15003351BB; Fri, 2 Nov 2001 10:59:46 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?utf-8?Q?sal?=" To: ndeason@ubiquity.net To: sdonovan@dynamicsoft.com To: jdrosen@dynamicsoft.com To: dean.willis@softarmor.com Cc: simple@mailman.dynamicsoft.com X-XaM3-API-Version: 2.5 X-type: 0 X-SenderIP: 212.177.57.193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id FAA20591 Subject: [Simple] =?iso-8859-1?Q?problem:_how_upload_presence_document=3F?= 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, 2 Nov 2001 10:59:45 +0100 Content-Transfer-Encoding: 8bit i think that this question: "upload presence document" is a critical issue. there isn't a standard procedure to upload and to modify the presence document, but it is the source of the presence status ... if the UA... if the PUA change its media capability, or change its status, it MUST refresh the presence document. the upload must be made through the protocol sip!!! and not push the presence doc via another protocol, such as HTTP POST. I agree with Steven Donovan when he says in the draft "Requirement for Pubblication of SIP related service data" : "... it is felt that the SIP REGISTER request is NOT the appropriate mechanisme for handing this loading od SIP service information..." but i'm not sure that a generalization of the REGISTER function, as proposed in the draft, is a good idea The use of the method REGISTER, for the upload,introduces one series of problems, just one example: the expiration of the Presence document and the expiration of the current communication addresses (i.e. Contact Addres) are different... I have instead a proposed other: the use of method NOTIFY... this method is already used for send the presence state to a particular subscriber... the its generalization for the upload or refresh of Presence Document is very simple and has the advantage of not modify/generalization a very important message for sip as REGISTER... which is your opinion ? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 05:56:28 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29073 for ; Fri, 2 Nov 2001 05:56:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2AsVb7003209; Fri, 2 Nov 2001 05:54:31 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20789; Fri, 2 Nov 2001 05:56:03 -0500 (EST) Received: from mailrelay.bluelabs.se (mailrelay.bluelabs.se [194.17.38.34]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20778 for ; Fri, 2 Nov 2001 05:55:59 -0500 (EST) Received: from blnet-sth-vscan.bluelabs.se (blnet-sth-vscan1.bluelabs.se [194.17.38.247]) by mailrelay.bluelabs.se (Postfix) with SMTP id 92BB717C9 for ; Fri, 2 Nov 2001 11:55:40 +0100 (CET) Received: FROM blue-sth1.bluelabs.se BY blnet-sth-vscan.bluelabs.se ; Fri Nov 02 11:55:40 2001 +0100 Received: from oden ([194.17.35.12]) by blue-sth1.bluelabs.se (Lotus Domino Release 5.0.6a) with ESMTP id 2001110211553977:12095 ; Fri, 2 Nov 2001 11:55:39 +0100 From: =?iso-8859-1?Q?H=E5kan_Jonsson?= To: "'sal'" , , Subject: SV: [Simple] problem: how upload presence document? Message-ID: <01d801c1638e$3f2500a0$0c2311c2@oden> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal X-MIMETrack: Itemize by SMTP Server on Blue-sth1/srv/Bluelabs(Release 5.0.6a |January 17, 2001) at 2001-11-02 11:55:39, Serialize by Router on Blue-sth1/srv/Bluelabs(Release 5.0.6a |January 17, 2001) at 2001-11-02 11:55:40, Serialize complete at 2001-11-02 11:55:40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA20778 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, 2 Nov 2001 12:05:13 +0100 Content-Transfer-Encoding: 8bit I think that the letting the PA subscribe to the PUAs presence document is a nice approach, since you can use it as it is. One thing you would need to add to the NOTIFY is an Expires header and interpret that as the expiration time for a soft state, to satisfy the requirements in draft-donovan..., but I think that is allowed by the current sip-events draft. The PUA can manipulate presence information in a number of ways, which is good. For presence documents I don't think we should limit ourselves to one way, but specifying a mechanism to upload service data using SIP in general as suggested in Donovan's draft is desirable, and should be one of the ways to upload presence documents. As Donovan suggests in his draft, the actions to be taken using the uploaded data could be put in the body or in an extension of SIP methods, headers etc. I think defining a new event type for each type of data would result in a lot of event types. Using NOTIFY, SUBSCRIBE with one new event type: servicedata, and letting the actual body contain the specific data manipulation actions to be done in a service specific language, is the most general and clear-cut way to do it. On the other hand, if there only a few service data types needed, we could define specific event types for these. Donovan mentions presence documents and CPL scripts; what other types are needed? Håkan ----------------- Håkan Jonsson Drottninggatan 18 BlueLabs South AB 21189 Malmö http://www.bluelabs.se Sweden > -----Ursprungligt meddelande----- > Från: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com] För sal > Skickat: den 2 november 2001 11:00 > Till: ndeason@ubiquity.net; sdonovan@dynamicsoft.com; > jdrosen@dynamicsoft.com; dean.willis@softarmor.com > Kopia: simple@mailman.dynamicsoft.com > Ämne: [Simple] problem: how upload presence document? > > > i think that this question: "upload presence document" is a > critical issue. > > there isn't a standard procedure to upload and to modify the > presence document, but it is the source of the presence status ... > if the UA... if the PUA change its media capability, or > change its status, it MUST refresh the presence document. > > > the upload must be made through the protocol sip!!! > and not push the presence doc via another protocol, such as HTTP POST. > > > I agree with Steven Donovan when he says in the draft > "Requirement for Pubblication of SIP related service data" > : "... it is felt that the SIP REGISTER request is NOT the > appropriate mechanisme for handing this loading od SIP > service information..." but i'm not sure that a > generalization of the REGISTER function, as proposed in the > draft, is a good idea > > > The use of the method REGISTER, for the upload,introduces one > series of problems, just one example: the expiration of the > Presence document and the expiration of the current > communication addresses (i.e. Contact Addres) are different... > > I have instead a proposed other: > the use of method NOTIFY... > this method is already used for send the presence state to > a particular subscriber... > the its generalization for the upload or refresh of Presence > Document is very simple and has the advantage of not > modify/generalization a very important message for sip as REGISTER... > > > which is your opinion ? > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com > http://mailman.dynamicsoft.com/mailman/listinf> o/simple > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 12:40:45 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12765 for ; Fri, 2 Nov 2001 12:40:44 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2Hblb7005963; Fri, 2 Nov 2001 12:37:47 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22033; Fri, 2 Nov 2001 12:39:04 -0500 (EST) Received: from ix.netcorps.com (ix.netcorps.com [216.65.52.9]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22022 for ; Fri, 2 Nov 2001 12:38:28 -0500 (EST) Received: from indigosw.com (194-78-202-25.pro.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id JAA27357 for ; Fri, 2 Nov 2001 09:40:19 -0800 (PST) Message-ID: <3BE2D9F4.D224D432@indigosw.com> From: Jean-Luc Sonnet X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] 9th SipIt 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, 02 Nov 2001 18:37:56 +0100 Content-Transfer-Encoding: 7bit Hi all, I would like to know if some of the companies that will participate in the 9th SipIt in San Diego will have a Presence Server or a PIM client with which we could run some tests ? Jean-Luc Sonnet. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 15:13:43 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17045 for ; Fri, 2 Nov 2001 15:13:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2KAXb7007503; Fri, 2 Nov 2001 15:10:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22506; Fri, 2 Nov 2001 15:12:04 -0500 (EST) 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 PAA22494 for ; Fri, 2 Nov 2001 15:11:17 -0500 (EST) 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 OAA22773 for ; Fri, 2 Nov 2001 14:10:49 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 2 Nov 2001 14:03:42 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 14:09:40 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EAC5097@zrc2c012.us.nortel.com> From: "Brian Stucker" To: =?iso-8859-1?Q?H=E5kan_Jonsson?= , "'sal'" , simple , sdonovan Subject: RE: [Simple] problem: how upload presence document? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C163DA.4CB11AA0" 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: Fri, 2 Nov 2001 14:09:38 -0600 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_01C163DA.4CB11AA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, REGISTER is already out there and in use, and there's a lot to be said to sticking with something that's already been developed (for CPL) to do basically the same thing that we need as a general mechanism. I=20 would posit that this alone makes it a good candidate for a default=20 mechanism to upload presence fragments into the network.=20 Brian -----Original Message----- From: H=E5kan Jonsson [mailto:hakan.jonsson@bluelabs.se] Sent: Friday, November 02, 2001 5:05 AM To: 'sal'; simple; sdonovan Subject: SV: [Simple] problem: how upload presence document? I think that the letting the PA subscribe to the PUAs presence document is a nice approach, since you can use it as it is. One thing you would need to add to the NOTIFY is an Expires header and interpret that as = the expiration time for a soft state, to satisfy the requirements in draft-donovan..., but I think that is allowed by the current sip-events draft. The PUA can manipulate presence information in a number of ways, which is good. For presence documents I don't think we should limit ourselves to one way, but specifying a mechanism to upload service data using SIP in general as suggested in Donovan's draft is desirable, and should be one of the ways to upload presence documents. As Donovan suggests in his draft, the actions to be taken using the uploaded data could be put in the body or in an extension of SIP methods, headers etc. I think defining a new event type for each type = of data would result in a lot of event types. Using NOTIFY, SUBSCRIBE with one new event type: servicedata, and letting the actual body contain = the specific data manipulation actions to be done in a service specific language, is the most general and clear-cut way to do it. On the other hand, if there only a few service data types needed, we could define specific event types for these. Donovan mentions presence documents and CPL scripts; what other types are needed? H=E5kan ----------------- H=E5kan Jonsson Drottninggatan 18 BlueLabs South AB 21189 Malm=F6 http://www.bluelabs.se Sweden > -----Ursprungligt meddelande----- > Fr=E5n: simple-admin@mailman.dynamicsoft.com=20 > [mailto:simple-admin@mailman.dynamicsoft.com] F=F6r sal > Skickat: den 2 november 2001 11:00 > Till: ndeason@ubiquity.net; sdonovan@dynamicsoft.com;=20 > jdrosen@dynamicsoft.com; dean.willis@softarmor.com > Kopia: simple@mailman.dynamicsoft.com > =C4mne: [Simple] problem: how upload presence document? >=20 >=20 > i think that this question: "upload presence document" is a=20 > critical issue. >=20 > there isn't a standard procedure to upload and to modify the=20 > presence document, but it is the source of the presence status ...=20 > if the UA... if the PUA change its media capability, or=20 > change its status, it MUST refresh the presence document. >=20 >=20 > the upload must be made through the protocol sip!!! > and not push the presence doc via another protocol, such as HTTP = POST. >=20 >=20 > I agree with Steven Donovan when he says in the draft=20 > "Requirement for Pubblication of SIP related service data" > : "... it is felt that the SIP REGISTER request is NOT the=20 > appropriate mechanisme for handing this loading od SIP=20 > service information..." but i'm not sure that a=20 > generalization of the REGISTER function, as proposed in the=20 > draft, is a good idea >=20 >=20 > The use of the method REGISTER, for the upload,introduces one=20 > series of problems, just one example: the expiration of the=20 > Presence document and the expiration of the current=20 > communication addresses (i.e. Contact Addres) are different... >=20 > I have instead a proposed other: > the use of method NOTIFY... > this method is already used for send the presence state to > a particular subscriber...=20 > the its generalization for the upload or refresh of Presence=20 > Document is very simple and has the advantage of not=20 > modify/generalization a very important message for sip as REGISTER... >=20 >=20 > which is your opinion ?=20 > _______________________________________________ > simple mailing list > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinf> o/simple >=20 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C163DA.4CB11AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] problem: how upload presence document?

Well, REGISTER is already out there and in use, and = there's a lot to be
said to sticking with something that's already been = developed (for CPL)
to do basically the same thing that we need as a = general mechanism. I
would posit that this alone makes it a good = candidate for a default
mechanism to upload presence fragments into the = network.

Brian

-----Original Message-----
From: H=E5kan Jonsson [mailto:hakan.jonsson@bluelabs.= se]
Sent: Friday, November 02, 2001 5:05 AM
To: 'sal'; simple; sdonovan
Subject: SV: [Simple] problem: how upload presence = document?


I think that the letting the PA subscribe to the PUAs = presence document
is a nice approach, since you can use it as it is. = One thing you would
need to add to the NOTIFY is an Expires header and = interpret that as the
expiration time for a soft state, to satisfy the = requirements in
draft-donovan..., but I think that is allowed by the = current sip-events
draft.

The PUA can manipulate presence information in a = number of ways, which
is good. For presence documents I don't think we = should limit ourselves
to one way, but specifying a mechanism to upload = service data using SIP
in general as suggested in Donovan's draft is = desirable, and should be
one of the ways to upload presence documents.

As Donovan suggests in his draft, the actions to be = taken using the
uploaded data could be put in the body or in an = extension of SIP
methods, headers etc. I think defining a new event = type for each type of
data would result in a lot of event types. Using = NOTIFY, SUBSCRIBE with
one new event type: servicedata, and letting the = actual body contain the
specific data manipulation actions to be done in a = service specific
language, is the most general and clear-cut way to = do it. On the other
hand, if there only a few service data types needed, = we could define
specific event types for these. Donovan mentions = presence documents and
CPL scripts; what other types are needed?

H=E5kan
-----------------
H=E5kan = Jonsson           = ;   Drottninggatan 18
BlueLabs South = AB          21189 = Malm=F6
http://www.bluelabs.se     = Sweden


> -----Ursprungligt meddelande-----
> Fr=E5n: simple-admin@mailman.dynamicsoft.com =
> [mailto:simple-admin= @mailman.dynamicsoft.com] F=F6r sal
> Skickat: den 2 november 2001 11:00
> Till: ndeason@ubiquity.net; = sdonovan@dynamicsoft.com;
> jdrosen@dynamicsoft.com; = dean.willis@softarmor.com
> Kopia: simple@mailman.dynamicsoft.com
> =C4mne: [Simple] problem: how upload presence = document?
>
>
> i think that this question: "upload = presence document" is a
> critical issue.
>
> there isn't a standard procedure to upload and = to modify the
> presence document, but it is the source of the = presence status ...
> if the UA... if the PUA change its media = capability, or
> change its status, it MUST refresh the presence = document.
>
>
> the upload must be made through the protocol = sip!!!
> and not push the presence doc via another = protocol, such as HTTP POST.
>
>
> I agree with Steven Donovan when he says in the = draft
> "Requirement for Pubblication of SIP = related service data"
> : "... it is felt that the SIP REGISTER = request is NOT the
> appropriate mechanisme for handing this loading = od SIP
> service information..." but i'm not sure = that a
> generalization of the REGISTER function, as = proposed in the
> draft, is a good idea
>
>
> The use of the method REGISTER, for the = upload,introduces one
> series of problems, just one example: the = expiration of the
> Presence document and the expiration of the = current
> communication addresses (i.e. Contact Addres) = are different...
>
> I have instead a proposed other:
> the use of method NOTIFY...
> this method is already used for send the = presence state to
> a particular subscriber...
> the its generalization for the upload or = refresh of Presence
> Document is very simple and has the advantage = of not
> modify/generalization a very important message = for sip as REGISTER...
>
>
> which is your opinion ?
> = _______________________________________________
> simple mailing list
> simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinf>= o/simple
>

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

------_=_NextPart_001_01C163DA.4CB11AA0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 16:29:25 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18984 for ; Fri, 2 Nov 2001 16:29:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2LQYb7008371; Fri, 2 Nov 2001 16:26:34 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22745; Fri, 2 Nov 2001 16:28:04 -0500 (EST) 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 QAA22734 for ; Fri, 2 Nov 2001 16:27:00 -0500 (EST) 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 fA2LPIb7008364; Fri, 2 Nov 2001 16:25:18 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 16:26:34 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E752@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Brian Stucker'" , =?iso-8859-1?Q?H=E5k?= =?iso-8859-1?Q?an_Jonsson?= , "'sal'" , simple , Steve Donovan Subject: RE: [Simple] problem: how upload presence document? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C163E5.095DD710" 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, 2 Nov 2001 16:26:29 -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_01C163E5.095DD710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have as a group identified that it is not a good enough thing. =20 We have a defined mechanism that uses REGISTER for now, but we recognize that that is not the proper long term solution. =20 We've explored its shortcomings before, and don't need to do so here again - they are captured in Steve Donovan's draft. We were on the path to taking on defining a method for publishing presence data in SIMPLE when we realized there was a more general need, so we've handed that work off to SIP by way of SIPPING (which finally officially exists). We will have an item on our revised agenda to specify how this mechanism will be used for presence publication once its available. =20 In the meantime, we'll use Register and work around the warts. =20 RjS=20 =20 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, November 02, 2001 2:10 PM To: H=E5kan Jonsson; 'sal'; simple; sdonovan Subject: RE: [Simple] problem: how upload presence document? Well, REGISTER is already out there and in use, and there's a lot to be = said to sticking with something that's already been developed (for CPL) = to do basically the same thing that we need as a general mechanism. I=20 would posit that this alone makes it a good candidate for a default=20 mechanism to upload presence fragments into the network.=20 Brian=20 -----Original Message-----=20 From: H=E5kan Jonsson [ mailto:hakan.jonsson@bluelabs.se ]=20 Sent: Friday, November 02, 2001 5:05 AM=20 To: 'sal'; simple; sdonovan=20 Subject: SV: [Simple] problem: how upload presence document?=20 I think that the letting the PA subscribe to the PUAs presence document = is a nice approach, since you can use it as it is. One thing you would=20 need to add to the NOTIFY is an Expires header and interpret that as = the=20 expiration time for a soft state, to satisfy the requirements in=20 draft-donovan..., but I think that is allowed by the current sip-events = draft.=20 The PUA can manipulate presence information in a number of ways, which=20 is good. For presence documents I don't think we should limit ourselves = to one way, but specifying a mechanism to upload service data using SIP = in general as suggested in Donovan's draft is desirable, and should be=20 one of the ways to upload presence documents.=20 As Donovan suggests in his draft, the actions to be taken using the=20 uploaded data could be put in the body or in an extension of SIP=20 methods, headers etc. I think defining a new event type for each type = of=20 data would result in a lot of event types. Using NOTIFY, SUBSCRIBE with = one new event type: servicedata, and letting the actual body contain = the=20 specific data manipulation actions to be done in a service specific=20 language, is the most general and clear-cut way to do it. On the other=20 hand, if there only a few service data types needed, we could define=20 specific event types for these. Donovan mentions presence documents and = CPL scripts; what other types are needed?=20 H=E5kan=20 -----------------=20 H=E5kan Jonsson Drottninggatan 18=20 BlueLabs South AB 21189 Malm=F6=20 http://www.bluelabs.se Sweden=20 > -----Ursprungligt meddelande-----=20 > Fr=E5n: simple-admin@mailman.dynamicsoft.com=20 > [ mailto:simple-admin@mailman.dynamicsoft.com ] F=F6r sal=20 > Skickat: den 2 november 2001 11:00=20 > Till: ndeason@ubiquity.net; sdonovan@dynamicsoft.com;=20 > jdrosen@dynamicsoft.com; dean.willis@softarmor.com=20 > Kopia: simple@mailman.dynamicsoft.com=20 > =C4mne: [Simple] problem: how upload presence document?=20 >=20 >=20 > i think that this question: "upload presence document" is a=20 > critical issue.=20 >=20 > there isn't a standard procedure to upload and to modify the=20 > presence document, but it is the source of the presence status ...=20 > if the UA... if the PUA change its media capability, or=20 > change its status, it MUST refresh the presence document.=20 >=20 >=20 > the upload must be made through the protocol sip!!!=20 > and not push the presence doc via another protocol, such as HTTP = POST.=20 >=20 >=20 > I agree with Steven Donovan when he says in the draft=20 > "Requirement for Pubblication of SIP related service data"=20 > : "... it is felt that the SIP REGISTER request is NOT the=20 > appropriate mechanisme for handing this loading od SIP=20 > service information..." but i'm not sure that a=20 > generalization of the REGISTER function, as proposed in the=20 > draft, is a good idea=20 >=20 >=20 > The use of the method REGISTER, for the upload,introduces one=20 > series of problems, just one example: the expiration of the=20 > Presence document and the expiration of the current=20 > communication addresses (i.e. Contact Addres) are different...=20 >=20 > I have instead a proposed other:=20 > the use of method NOTIFY...=20 > this method is already used for send the presence state to=20 > a particular subscriber...=20 > the its generalization for the upload or refresh of Presence=20 > Document is very simple and has the advantage of not=20 > modify/generalization a very important message for sip as REGISTER... = >=20 >=20 > which is your opinion ?=20 > _______________________________________________=20 > simple mailing list=20 > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinf > o/simple=20 >=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple =20 ------_=_NextPart_001_01C163E5.095DD710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] problem: how upload presence document?
We=20 have as a group identified that it is not a good enough=20 thing.
 
We=20 have a defined mechanism that uses REGISTER for = now,
but we=20 recognize that that is not the proper long term = solution.
 
We've = explored its=20 shortcomings before, and don't need to do = so
here again - they are captured in Steve = Donovan's=20 draft. We were
on the path to taking on defining = a method=20 for publishing presence
data in SIMPLE when we realized there = was a more=20 general need,
so we've handed that work off to SIP by way = of SIPPING=20 (which finally
officially exists). We will = have an item=20 on our revised agenda to
specify how this mechanism will be used for = presence=20 publication
once its = available.
 
In the meantime, we'll use Register and = work=20 around the warts.
 
RjS 
 
 -----Original = Message-----
From:=20 Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: = Friday,=20 November 02, 2001 2:10 PM
To: H=E5kan Jonsson; 'sal'; simple; = sdonovan
Subject: RE: [Simple] problem: how upload presence=20 document?

Well, REGISTER is already out there and in use, and = there's a=20 lot to be
said to sticking with something = that's=20 already been developed (for CPL)
to do = basically the=20 same thing that we need as a general mechanism. I
would posit that this alone makes it a good candidate for a = default=20
mechanism to upload presence fragments into = the=20 network.

Brian

-----Original Message-----
From: H=E5kan=20 Jonsson [mailto:hakan.jonsson@bluelabs.= se]=20
Sent: Friday, November 02, 2001 5:05 AM =
To: 'sal'; simple; sdonovan
Subject: SV:=20 [Simple] problem: how upload presence document?


I think that the letting the PA subscribe to the = PUAs presence=20 document
is a nice approach, since you can = use it as=20 it is. One thing you would
need to add to = the NOTIFY=20 is an Expires header and interpret that as the
expiration time for a soft state, to satisfy the = requirements in=20
draft-donovan..., but I think that is allowed by = the current=20 sip-events
draft.

The PUA can manipulate presence information in a = number of=20 ways, which
is good. For presence documents = I don't=20 think we should limit ourselves
to one way, = but=20 specifying a mechanism to upload service data using SIP =
in general as suggested in Donovan's draft is desirable, and = should=20 be
one of the ways to upload presence=20 documents.

As Donovan suggests in his draft, the actions to be = taken=20 using the
uploaded data could be put in the = body or in=20 an extension of SIP
methods, headers etc. I = think=20 defining a new event type for each type of
data would=20 result in a lot of event types. Using NOTIFY, SUBSCRIBE with =
one new event type: servicedata, and letting the actual body = contain=20 the
specific data manipulation actions to = be done in a=20 service specific
language, is the most = general and=20 clear-cut way to do it. On the other
hand, = if there=20 only a few service data types needed, we could define =
specific event types for these. Donovan mentions presence = documents=20 and
CPL scripts; what other types are = needed?=20

H=E5kan
-----------------=20
H=E5kan=20 = Jonsson           = ;  =20 Drottninggatan 18
BlueLabs South=20 AB          21189 = Malm=F6=20
http://www.bluelabs.se     = Sweden=20


> -----Ursprungligt meddelande----- =
> Fr=E5n: simple-admin@mailman.dynamicsoft.com =
> [mailto:simple-admin= @mailman.dynamicsoft.com]=20 F=F6r sal
> Skickat: den 2 november 2001 = 11:00=20
> Till: ndeason@ubiquity.net; = sdonovan@dynamicsoft.com;=20
> jdrosen@dynamicsoft.com;=20 dean.willis@softarmor.com
> Kopia:=20 simple@mailman.dynamicsoft.com
> =C4mne: = [Simple]=20 problem: how upload presence document?
> =
>
> i think = that this=20 question: "upload presence document" is a
>=20 critical issue.
>
>=20 there isn't a standard procedure to upload and to modify the =
> presence document, but it is the source of the presence = status ...=20
> if the UA... if the PUA change its = media=20 capability, or
> change its status, it = MUST refresh=20 the presence document.
> =
>
> the upload must be made = through the=20 protocol sip!!!
> and not push the = presence doc via=20 another protocol, such as HTTP POST.
>=20
>
> I agree = with Steven=20 Donovan when he says in the draft
> = "Requirement=20 for Pubblication of SIP related service data"
> :=20 "... it is felt that the SIP REGISTER request is NOT the =
> appropriate mechanisme for handing this loading od SIP=20
> service information..." but i'm not = sure that a=20
> generalization of the REGISTER = function, as=20 proposed in the
> draft, is a good = idea=20
>
> =
> The use of the method REGISTER, for the = upload,introduces one=20
> series of problems, just one example: = the=20 expiration of the
> Presence document = and the=20 expiration of the current
> = communication addresses=20 (i.e. Contact Addres) are different...
> =
> I have instead a proposed = other:
> the use of method NOTIFY...
> this=20 method is already used for send the presence state to =
> a particular subscriber...
> the its=20 generalization for the upload or refresh of Presence
> Document is very simple and has the advantage of not=20
> modify/generalization a very important = message=20 for sip as REGISTER...
> =
>
> which is your opinion ?=20
>=20 _______________________________________________
>=20 simple mailing list
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinf>=20 o/simple
>

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

------_=_NextPart_001_01C163E5.095DD710-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 16:50:23 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19616 for ; Fri, 2 Nov 2001 16:50:22 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2LlXb7008628; Fri, 2 Nov 2001 16:47:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22847; Fri, 2 Nov 2001 16:49:05 -0500 (EST) 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 QAA22836 for ; Fri, 2 Nov 2001 16:48:59 -0500 (EST) 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 PAA25606 for ; Fri, 2 Nov 2001 15:48:42 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 2 Nov 2001 15:41:46 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 15:47:48 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EAC5285@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Robert Sparks , =?iso-8859-1?Q?H=E5kan_Jon?= =?iso-8859-1?Q?sson?= , "'sal'" , simple , Steve Donovan Cc: "Mary Barnes" , "Sriram Parameswar" , "Alex Nava" Subject: RE: [Simple] problem: how upload presence document? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C163E8.0343EBF0" 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: Fri, 2 Nov 2001 15:47:48 -0600 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_01C163E8.0343EBF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good enough. So this will appear in IETF-52, then? =20 Brian =20 -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, November 02, 2001 3:26 PM To: Stucker, Brian [NGB:B621:EXCH]; H=E5kan Jonsson; 'sal'; simple; = Steve Donovan Subject: RE: [Simple] problem: how upload presence document? We have as a group identified that it is not a good enough thing. =20 We have a defined mechanism that uses REGISTER for now, but we recognize that that is not the proper long term solution. =20 We've explored its shortcomings before, and don't need to do so here again - they are captured in Steve Donovan's draft. We were on the path to taking on defining a method for publishing presence data in SIMPLE when we realized there was a more general need, so we've handed that work off to SIP by way of SIPPING (which finally officially exists). We will have an item on our revised agenda to specify how this mechanism will be used for presence publication once its available. =20 In the meantime, we'll use Register and work around the warts. =20 RjS=20 =20 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, November 02, 2001 2:10 PM To: H=E5kan Jonsson; 'sal'; simple; sdonovan Subject: RE: [Simple] problem: how upload presence document? Well, REGISTER is already out there and in use, and there's a lot to be = said to sticking with something that's already been developed (for CPL) = to do basically the same thing that we need as a general mechanism. I=20 would posit that this alone makes it a good candidate for a default=20 mechanism to upload presence fragments into the network.=20 Brian=20 -----Original Message-----=20 From: H=E5kan Jonsson [ mailto:hakan.jonsson@bluelabs.se ]=20 Sent: Friday, November 02, 2001 5:05 AM=20 To: 'sal'; simple; sdonovan=20 Subject: SV: [Simple] problem: how upload presence document?=20 I think that the letting the PA subscribe to the PUAs presence document = is a nice approach, since you can use it as it is. One thing you would=20 need to add to the NOTIFY is an Expires header and interpret that as = the=20 expiration time for a soft state, to satisfy the requirements in=20 draft-donovan..., but I think that is allowed by the current sip-events = draft.=20 The PUA can manipulate presence information in a number of ways, which=20 is good. For presence documents I don't think we should limit ourselves = to one way, but specifying a mechanism to upload service data using SIP = in general as suggested in Donovan's draft is desirable, and should be=20 one of the ways to upload presence documents.=20 As Donovan suggests in his draft, the actions to be taken using the=20 uploaded data could be put in the body or in an extension of SIP=20 methods, headers etc. I think defining a new event type for each type = of=20 data would result in a lot of event types. Using NOTIFY, SUBSCRIBE with = one new event type: servicedata, and letting the actual body contain = the=20 specific data manipulation actions to be done in a service specific=20 language, is the most general and clear-cut way to do it. On the other=20 hand, if there only a few service data types needed, we could define=20 specific event types for these. Donovan mentions presence documents and = CPL scripts; what other types are needed?=20 H=E5kan=20 -----------------=20 H=E5kan Jonsson Drottninggatan 18=20 BlueLabs South AB 21189 Malm=F6=20 http://www.bluelabs.se Sweden=20 > -----Ursprungligt meddelande-----=20 > Fr=E5n: simple-admin@mailman.dynamicsoft.com=20 > [ mailto:simple-admin@mailman.dynamicsoft.com ] F=F6r sal=20 > Skickat: den 2 november 2001 11:00=20 > Till: ndeason@ubiquity.net; sdonovan@dynamicsoft.com;=20 > jdrosen@dynamicsoft.com; dean.willis@softarmor.com=20 > Kopia: simple@mailman.dynamicsoft.com=20 > =C4mne: [Simple] problem: how upload presence document?=20 >=20 >=20 > i think that this question: "upload presence document" is a=20 > critical issue.=20 >=20 > there isn't a standard procedure to upload and to modify the=20 > presence document, but it is the source of the presence status ...=20 > if the UA... if the PUA change its media capability, or=20 > change its status, it MUST refresh the presence document.=20 >=20 >=20 > the upload must be made through the protocol sip!!!=20 > and not push the presence doc via another protocol, such as HTTP = POST.=20 >=20 >=20 > I agree with Steven Donovan when he says in the draft=20 > "Requirement for Pubblication of SIP related service data"=20 > : "... it is felt that the SIP REGISTER request is NOT the=20 > appropriate mechanisme for handing this loading od SIP=20 > service information..." but i'm not sure that a=20 > generalization of the REGISTER function, as proposed in the=20 > draft, is a good idea=20 >=20 >=20 > The use of the method REGISTER, for the upload,introduces one=20 > series of problems, just one example: the expiration of the=20 > Presence document and the expiration of the current=20 > communication addresses (i.e. Contact Addres) are different...=20 >=20 > I have instead a proposed other:=20 > the use of method NOTIFY...=20 > this method is already used for send the presence state to=20 > a particular subscriber...=20 > the its generalization for the upload or refresh of Presence=20 > Document is very simple and has the advantage of not=20 > modify/generalization a very important message for sip as REGISTER... = >=20 >=20 > which is your opinion ?=20 > _______________________________________________=20 > simple mailing list=20 > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinf > o/simple=20 >=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple =20 ------_=_NextPart_001_01C163E8.0343EBF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] problem: how upload presence document?
Good=20 enough. So this will appear in IETF-52, then?
 
Brian
 
-----Original Message-----
From: Robert Sparks=20 [mailto:rsparks@dynamicsoft.com]
Sent: Friday, November 02, = 2001=20 3:26 PM
To: Stucker, Brian [NGB:B621:EXCH]; H=E5kan = Jonsson; 'sal';=20 simple; Steve Donovan
Subject: RE: [Simple] problem: how = upload=20 presence document?

We=20 have as a group identified that it is not a good enough=20 thing.
 
We=20 have a defined mechanism that uses REGISTER for = now,
but=20 we recognize that that is not the proper long term=20 solution.
 
We've=20 explored its shortcomings before, and don't need to do=20 so
here again - they are captured in Steve = Donovan's=20 draft. We were
on the path to taking on defining = a method=20 for publishing presence
data in SIMPLE when we = realized there was a more=20 general need,
so we've handed that work off to SIP by = way of=20 SIPPING (which finally
officially exists). We will = have an=20 item on our revised agenda to
specify how this mechanism will be used = for presence=20 publication
once its = available.
 
In the meantime, we'll use Register = and work=20 around the warts.
 
RjS 
 
 -----Original=20 Message-----
From: Brian Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Friday, November = 02, 2001=20 2:10 PM
To: H=E5kan Jonsson; 'sal'; simple;=20 sdonovan
Subject: RE: [Simple] problem: how upload presence = document?

Well, REGISTER is already out there and in use, = and there's=20 a lot to be
said to sticking with = something that's=20 already been developed (for CPL)
to do = basically the=20 same thing that we need as a general mechanism. I
would posit that this alone makes it a good candidate for = a default=20
mechanism to upload presence fragments = into the=20 network.

Brian

-----Original Message-----
From:=20 H=E5kan Jonsson [mailto:hakan.jonsson@bluelabs.= se]=20
Sent: Friday, November 02, 2001 5:05 AM =
To: 'sal'; simple; sdonovan
Subject: SV:=20 [Simple] problem: how upload presence document?


I think that the letting the PA subscribe to the = PUAs=20 presence document
is a nice approach, = since you can=20 use it as it is. One thing you would
need = to add to=20 the NOTIFY is an Expires header and interpret that as the =
expiration time for a soft state, to satisfy the = requirements=20 in
draft-donovan..., but I think that is = allowed by=20 the current sip-events
draft.

The PUA can manipulate presence information in a = number of=20 ways, which
is good. For presence = documents I don't=20 think we should limit ourselves
to one = way, but=20 specifying a mechanism to upload service data using SIP =
in general as suggested in Donovan's draft is desirable, = and should=20 be
one of the ways to upload presence=20 documents.

As Donovan suggests in his draft, the actions to = be taken=20 using the
uploaded data could be put in = the body or=20 in an extension of SIP
methods, headers = etc. I think=20 defining a new event type for each type of
data=20 would result in a lot of event types. Using NOTIFY, SUBSCRIBE = with=20
one new event type: servicedata, and letting the = actual=20 body contain the
specific data = manipulation actions=20 to be done in a service specific
language, is the=20 most general and clear-cut way to do it. On the other =
hand, if there only a few service data types needed, we = could=20 define
specific event types for these. = Donovan=20 mentions presence documents and
CPL = scripts; what=20 other types are needed?

H=E5kan
-----------------=20
H=E5kan=20 = Jonsson           = ;  =20 Drottninggatan 18
BlueLabs South=20 AB          21189 = Malm=F6=20
http://www.bluelabs.se    =20 Sweden


> -----Ursprungligt meddelande----- =
> Fr=E5n: simple-admin@mailman.dynamicsoft.com =
> [mailto:simple-admin= @mailman.dynamicsoft.com]=20 F=F6r sal
> Skickat: den 2 november = 2001=20 11:00
> Till: ndeason@ubiquity.net;=20 sdonovan@dynamicsoft.com;
>=20 jdrosen@dynamicsoft.com; dean.willis@softarmor.com
> Kopia: simple@mailman.dynamicsoft.com =
> =C4mne: [Simple] problem: how upload presence = document?=20
>
> =
> i think that this question: "upload presence = document" is a=20
> critical issue.
>=20
> there isn't a standard procedure to = upload and=20 to modify the
> presence document, but = it is the=20 source of the presence status ...
> if = the UA...=20 if the PUA change its media capability, or
>=20 change its status, it MUST refresh the presence document. =
>
>
> the=20 upload must be made through the protocol sip!!!
>=20 and not push the presence doc via another protocol, such as HTTP=20 POST.
>
> =
> I agree with Steven Donovan when he = says in the=20 draft
> "Requirement for Pubblication = of SIP=20 related service data"
> : "... it is = felt that=20 the SIP REGISTER request is NOT the
> = appropriate=20 mechanisme for handing this loading od SIP
>=20 service information..." but i'm not sure that a
>=20 generalization of the REGISTER function, as proposed in the =
> draft, is a good idea
>=20
>
> The = use of the=20 method REGISTER, for the upload,introduces one
>=20 series of problems, just one example: the expiration of the =
> Presence document and the expiration of the current=20
> communication addresses (i.e. = Contact Addres)=20 are different...
>
> I=20 have instead a proposed other:
> the = use of=20 method NOTIFY...
> this method is = already used=20 for send the presence state to
> a = particular=20 subscriber...
> the its generalization = for the=20 upload or refresh of Presence
> = Document is very=20 simple and has the advantage of not
>=20 modify/generalization a very important message for sip as = REGISTER...=20
>
> =
> which is your opinion ?
>=20 _______________________________________________
>=20 simple mailing list
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinf>=20 o/simple
>

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

------_=_NextPart_001_01C163E8.0343EBF0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 16:52:28 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19694 for ; Fri, 2 Nov 2001 16:52:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2LnXb7008695; Fri, 2 Nov 2001 16:49:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22875; Fri, 2 Nov 2001 16:51:05 -0500 (EST) 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 QAA22864 for ; Fri, 2 Nov 2001 16:50:59 -0500 (EST) 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 PAA26202 for ; Fri, 2 Nov 2001 15:50:41 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 2 Nov 2001 15:43:40 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 15:49:42 -0600 Message-ID: From: "Sriram Parameswar" To: "'Robert Sparks'" , "Brian Stucker" , =?iso-8859-1?Q?=27H=E5kan_Jonsson=27?= , "'sal'" , "'simple'" , "'Steve Donovan'" Subject: RE: [Simple] problem: how upload presence document? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C163E8.47692480" 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: Fri, 2 Nov 2001 15:49:42 -0600 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_01C163E8.47692480 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert: =20 Is there a PUBLISH - 200 OK in the works? If so, lets discuss its = merits and de-merits in the SIMPLE list. This will avoid a whole lot of backwards compatibility issues down the road. =20 Regards, =20 Sriram __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-685-3563=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, November 02, 2001 3:26 PM To: Stucker, Brian [NGB:B621:EXCH]; H=E5kan Jonsson; 'sal'; simple; = Steve Donovan Subject: RE: [Simple] problem: how upload presence document? We have as a group identified that it is not a good enough thing. =20 We have a defined mechanism that uses REGISTER for now, but we recognize that that is not the proper long term solution. =20 We've explored its shortcomings before, and don't need to do so here again - they are captured in Steve Donovan's draft. We were on the path to taking on defining a method for publishing presence data in SIMPLE when we realized there was a more general need, so we've handed that work off to SIP by way of SIPPING (which finally officially exists). We will have an item on our revised agenda to specify how this mechanism will be used for presence publication once its available. =20 In the meantime, we'll use Register and work around the warts. =20 RjS=20 =20 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, November 02, 2001 2:10 PM To: H=E5kan Jonsson; 'sal'; simple; sdonovan Subject: RE: [Simple] problem: how upload presence document? Well, REGISTER is already out there and in use, and there's a lot to be = said to sticking with something that's already been developed (for CPL) = to do basically the same thing that we need as a general mechanism. I=20 would posit that this alone makes it a good candidate for a default=20 mechanism to upload presence fragments into the network.=20 Brian=20 -----Original Message-----=20 From: H=E5kan Jonsson [ mailto:hakan.jonsson@bluelabs.se ]=20 Sent: Friday, November 02, 2001 5:05 AM=20 To: 'sal'; simple; sdonovan=20 Subject: SV: [Simple] problem: how upload presence document?=20 I think that the letting the PA subscribe to the PUAs presence document = is a nice approach, since you can use it as it is. One thing you would=20 need to add to the NOTIFY is an Expires header and interpret that as = the=20 expiration time for a soft state, to satisfy the requirements in=20 draft-donovan..., but I think that is allowed by the current sip-events = draft.=20 The PUA can manipulate presence information in a number of ways, which=20 is good. For presence documents I don't think we should limit ourselves = to one way, but specifying a mechanism to upload service data using SIP = in general as suggested in Donovan's draft is desirable, and should be=20 one of the ways to upload presence documents.=20 As Donovan suggests in his draft, the actions to be taken using the=20 uploaded data could be put in the body or in an extension of SIP=20 methods, headers etc. I think defining a new event type for each type = of=20 data would result in a lot of event types. Using NOTIFY, SUBSCRIBE with = one new event type: servicedata, and letting the actual body contain = the=20 specific data manipulation actions to be done in a service specific=20 language, is the most general and clear-cut way to do it. On the other=20 hand, if there only a few service data types needed, we could define=20 specific event types for these. Donovan mentions presence documents and = CPL scripts; what other types are needed?=20 H=E5kan=20 -----------------=20 H=E5kan Jonsson Drottninggatan 18=20 BlueLabs South AB 21189 Malm=F6=20 http://www.bluelabs.se Sweden=20 > -----Ursprungligt meddelande-----=20 > Fr=E5n: simple-admin@mailman.dynamicsoft.com=20 > [ mailto:simple-admin@mailman.dynamicsoft.com ] F=F6r sal=20 > Skickat: den 2 november 2001 11:00=20 > Till: ndeason@ubiquity.net; sdonovan@dynamicsoft.com;=20 > jdrosen@dynamicsoft.com; dean.willis@softarmor.com=20 > Kopia: simple@mailman.dynamicsoft.com=20 > =C4mne: [Simple] problem: how upload presence document?=20 >=20 >=20 > i think that this question: "upload presence document" is a=20 > critical issue.=20 >=20 > there isn't a standard procedure to upload and to modify the=20 > presence document, but it is the source of the presence status ...=20 > if the UA... if the PUA change its media capability, or=20 > change its status, it MUST refresh the presence document.=20 >=20 >=20 > the upload must be made through the protocol sip!!!=20 > and not push the presence doc via another protocol, such as HTTP = POST.=20 >=20 >=20 > I agree with Steven Donovan when he says in the draft=20 > "Requirement for Pubblication of SIP related service data"=20 > : "... it is felt that the SIP REGISTER request is NOT the=20 > appropriate mechanisme for handing this loading od SIP=20 > service information..." but i'm not sure that a=20 > generalization of the REGISTER function, as proposed in the=20 > draft, is a good idea=20 >=20 >=20 > The use of the method REGISTER, for the upload,introduces one=20 > series of problems, just one example: the expiration of the=20 > Presence document and the expiration of the current=20 > communication addresses (i.e. Contact Addres) are different...=20 >=20 > I have instead a proposed other:=20 > the use of method NOTIFY...=20 > this method is already used for send the presence state to=20 > a particular subscriber...=20 > the its generalization for the upload or refresh of Presence=20 > Document is very simple and has the advantage of not=20 > modify/generalization a very important message for sip as REGISTER... = >=20 >=20 > which is your opinion ?=20 > _______________________________________________=20 > simple mailing list=20 > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinf > o/simple=20 >=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple =20 ------_=_NextPart_001_01C163E8.47692480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] problem: how upload presence document?
Robert:
 
Is=20 there a PUBLISH - 200 OK in the works? If so, lets discuss its = merits and=20 de-merits in the SIMPLE list. This will avoid a whole lot of = backwards=20 compatibility issues down the road.
 
Regards,
 
Sriram
__________________________________________ =
Sriram=20 Parameswar          &n= bsp;  =20 Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563 =
Nortel Networks, Richardson USA  = Email: sriramp@nortelnetworks.com =
-----Original Message-----
From: Robert Sparks=20 [mailto:rsparks@dynamicsoft.com]
Sent: Friday, November 02, = 2001=20 3:26 PM
To: Stucker, Brian [NGB:B621:EXCH]; H=E5kan = Jonsson; 'sal';=20 simple; Steve Donovan
Subject: RE: [Simple] problem: how = upload=20 presence document?

We=20 have as a group identified that it is not a good enough=20 thing.
 
We=20 have a defined mechanism that uses REGISTER for = now,
but=20 we recognize that that is not the proper long term=20 solution.
 
We've=20 explored its shortcomings before, and don't need to do=20 so
here again - they are captured in Steve = Donovan's=20 draft. We were
on the path to taking on defining = a method=20 for publishing presence
data in SIMPLE when we = realized there was a more=20 general need,
so we've handed that work off to SIP by = way of=20 SIPPING (which finally
officially exists). We will = have an=20 item on our revised agenda to
specify how this mechanism will be used = for presence=20 publication
once its = available.
 
In the meantime, we'll use Register = and work=20 around the warts.
 
RjS 
 
 -----Original=20 Message-----
From: Brian Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Friday, November = 02, 2001=20 2:10 PM
To: H=E5kan Jonsson; 'sal'; simple;=20 sdonovan
Subject: RE: [Simple] problem: how upload presence = document?

Well, REGISTER is already out there and in use, = and there's=20 a lot to be
said to sticking with = something that's=20 already been developed (for CPL)
to do = basically the=20 same thing that we need as a general mechanism. I
would posit that this alone makes it a good candidate for = a default=20
mechanism to upload presence fragments = into the=20 network.

Brian

-----Original Message-----
From:=20 H=E5kan Jonsson [mailto:hakan.jonsson@bluelabs.= se]=20
Sent: Friday, November 02, 2001 5:05 AM =
To: 'sal'; simple; sdonovan
Subject: SV:=20 [Simple] problem: how upload presence document?


I think that the letting the PA subscribe to the = PUAs=20 presence document
is a nice approach, = since you can=20 use it as it is. One thing you would
need = to add to=20 the NOTIFY is an Expires header and interpret that as the =
expiration time for a soft state, to satisfy the = requirements=20 in
draft-donovan..., but I think that is = allowed by=20 the current sip-events
draft.

The PUA can manipulate presence information in a = number of=20 ways, which
is good. For presence = documents I don't=20 think we should limit ourselves
to one = way, but=20 specifying a mechanism to upload service data using SIP =
in general as suggested in Donovan's draft is desirable, = and should=20 be
one of the ways to upload presence=20 documents.

As Donovan suggests in his draft, the actions to = be taken=20 using the
uploaded data could be put in = the body or=20 in an extension of SIP
methods, headers = etc. I think=20 defining a new event type for each type of
data=20 would result in a lot of event types. Using NOTIFY, SUBSCRIBE = with=20
one new event type: servicedata, and letting the = actual=20 body contain the
specific data = manipulation actions=20 to be done in a service specific
language, is the=20 most general and clear-cut way to do it. On the other =
hand, if there only a few service data types needed, we = could=20 define
specific event types for these. = Donovan=20 mentions presence documents and
CPL = scripts; what=20 other types are needed?

H=E5kan
-----------------=20
H=E5kan=20 = Jonsson           = ;  =20 Drottninggatan 18
BlueLabs South=20 AB          21189 = Malm=F6=20
http://www.bluelabs.se    =20 Sweden


> -----Ursprungligt meddelande----- =
> Fr=E5n: simple-admin@mailman.dynamicsoft.com =
> [mailto:simple-admin= @mailman.dynamicsoft.com]=20 F=F6r sal
> Skickat: den 2 november = 2001=20 11:00
> Till: ndeason@ubiquity.net;=20 sdonovan@dynamicsoft.com;
>=20 jdrosen@dynamicsoft.com; dean.willis@softarmor.com
> Kopia: simple@mailman.dynamicsoft.com =
> =C4mne: [Simple] problem: how upload presence = document?=20
>
> =
> i think that this question: "upload presence = document" is a=20
> critical issue.
>=20
> there isn't a standard procedure to = upload and=20 to modify the
> presence document, but = it is the=20 source of the presence status ...
> if = the UA...=20 if the PUA change its media capability, or
>=20 change its status, it MUST refresh the presence document. =
>
>
> the=20 upload must be made through the protocol sip!!!
>=20 and not push the presence doc via another protocol, such as HTTP=20 POST.
>
> =
> I agree with Steven Donovan when he = says in the=20 draft
> "Requirement for Pubblication = of SIP=20 related service data"
> : "... it is = felt that=20 the SIP REGISTER request is NOT the
> = appropriate=20 mechanisme for handing this loading od SIP
>=20 service information..." but i'm not sure that a
>=20 generalization of the REGISTER function, as proposed in the =
> draft, is a good idea
>=20
>
> The = use of the=20 method REGISTER, for the upload,introduces one
>=20 series of problems, just one example: the expiration of the <= BR>> Presence document and the expiration of the current=20
> communication addresses (i.e. = Contact Addres)=20 are different...
>
> I=20 have instead a proposed other:
> the = use of=20 method NOTIFY...
> this method is = already used=20 for send the presence state to
> a = particular=20 subscriber...
> the its generalization = for the=20 upload or refresh of Presence
> = Document is very=20 simple and has the advantage of not
>=20 modify/generalization a very important message for sip as = REGISTER...=20
>
> =
> which is your opinion ?
>=20 _______________________________________________
>=20 simple mailing list
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinf>=20 o/simple
>

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

------_=_NextPart_001_01C163E8.47692480-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 17:10:24 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20040 for ; Fri, 2 Nov 2001 17:10:23 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2M7Wb7008895; Fri, 2 Nov 2001 17:07:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22968; Fri, 2 Nov 2001 17:09:04 -0500 (EST) 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 RAA22957 for ; Fri, 2 Nov 2001 17:08:06 -0500 (EST) 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 fA2M6Vb7008888; Fri, 2 Nov 2001 17:06:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 17:07:46 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E753@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Sriram Parameswar'" , Robert Sparks , "'simple'" , Steve Donovan Subject: RE: [Simple] problem: how upload presence document? MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C163EA.C5EC2850" 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, 2 Nov 2001 17:07:33 -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_01C163EA.C5EC2850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The time for discussing it here is passed. It started here, but has moved to the SIPPING working group. We have been very careful make sure the requirements for presence publication are communicated there, starting with=20 draft-donovan-publish-requirements-00.txt and continuing through the participation of several members from this group. =20 If you have a vested interest the outcome of that work and are not already on the sipping list, go join it. (see http://www.ietf.org/html.charters/sipping-charter.html ) Be sure to comment on the donovan draft if you see something missing. =20 I notice that its new charter doesn't explicitly call out working on the publish mechanism - I'm in the process of finding out what happened to it.=20 =20 RjS -----Original Message----- From: Sriram Parameswar [mailto:sriramp@nortelnetworks.com] Sent: Friday, November 02, 2001 3:50 PM To: 'Robert Sparks'; Brian Stucker; 'H=E5kan Jonsson'; 'sal'; 'simple'; = 'Steve Donovan' Subject: RE: [Simple] problem: how upload presence document? Robert: =20 Is there a PUBLISH - 200 OK in the works? If so, lets discuss its = merits and de-merits in the SIMPLE list. This will avoid a whole lot of backwards compatibility issues down the road. =20 Regards, =20 Sriram __________________________________________=20 Sriram Parameswar Phone: 972-685-8540=20 Interactive Multimedia Server (IMS) Fax: 972-685-3563=20 Nortel Networks, Richardson USA Email: sriramp@nortelnetworks.com=20 -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Friday, November 02, 2001 3:26 PM To: Stucker, Brian [NGB:B621:EXCH]; H=E5kan Jonsson; 'sal'; simple; = Steve Donovan Subject: RE: [Simple] problem: how upload presence document? We have as a group identified that it is not a good enough thing. =20 We have a defined mechanism that uses REGISTER for now, but we recognize that that is not the proper long term solution. =20 We've explored its shortcomings before, and don't need to do so here again - they are captured in Steve Donovan's draft. We were on the path to taking on defining a method for publishing presence data in SIMPLE when we realized there was a more general need, so we've handed that work off to SIP by way of SIPPING (which finally officially exists). We will have an item on our revised agenda to specify how this mechanism will be used for presence publication once its available. =20 In the meantime, we'll use Register and work around the warts. =20 RjS=20 =20 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, November 02, 2001 2:10 PM To: H=E5kan Jonsson; 'sal'; simple; sdonovan Subject: RE: [Simple] problem: how upload presence document? Well, REGISTER is already out there and in use, and there's a lot to be = said to sticking with something that's already been developed (for CPL) = to do basically the same thing that we need as a general mechanism. I=20 would posit that this alone makes it a good candidate for a default=20 mechanism to upload presence fragments into the network.=20 Brian=20 -----Original Message-----=20 From: H=E5kan Jonsson [ mailto:hakan.jonsson@bluelabs.se ]=20 Sent: Friday, November 02, 2001 5:05 AM=20 To: 'sal'; simple; sdonovan=20 Subject: SV: [Simple] problem: how upload presence document?=20 I think that the letting the PA subscribe to the PUAs presence document = is a nice approach, since you can use it as it is. One thing you would=20 need to add to the NOTIFY is an Expires header and interpret that as = the=20 expiration time for a soft state, to satisfy the requirements in=20 draft-donovan..., but I think that is allowed by the current sip-events = draft.=20 The PUA can manipulate presence information in a number of ways, which=20 is good. For presence documents I don't think we should limit ourselves = to one way, but specifying a mechanism to upload service data using SIP = in general as suggested in Donovan's draft is desirable, and should be=20 one of the ways to upload presence documents.=20 As Donovan suggests in his draft, the actions to be taken using the=20 uploaded data could be put in the body or in an extension of SIP=20 methods, headers etc. I think defining a new event type for each type = of=20 data would result in a lot of event types. Using NOTIFY, SUBSCRIBE with = one new event type: servicedata, and letting the actual body contain = the=20 specific data manipulation actions to be done in a service specific=20 language, is the most general and clear-cut way to do it. On the other=20 hand, if there only a few service data types needed, we could define=20 specific event types for these. Donovan mentions presence documents and = CPL scripts; what other types are needed?=20 H=E5kan=20 -----------------=20 H=E5kan Jonsson Drottninggatan 18=20 BlueLabs South AB 21189 Malm=F6=20 http://www.bluelabs.se Sweden=20 > -----Ursprungligt meddelande-----=20 > Fr=E5n: simple-admin@mailman.dynamicsoft.com=20 > [ mailto:simple-admin@mailman.dynamicsoft.com ] F=F6r sal=20 > Skickat: den 2 november 2001 11:00=20 > Till: ndeason@ubiquity.net; sdonovan@dynamicsoft.com;=20 > jdrosen@dynamicsoft.com; dean.willis@softarmor.com=20 > Kopia: simple@mailman.dynamicsoft.com=20 > =C4mne: [Simple] problem: how upload presence document?=20 >=20 >=20 > i think that this question: "upload presence document" is a=20 > critical issue.=20 >=20 > there isn't a standard procedure to upload and to modify the=20 > presence document, but it is the source of the presence status ...=20 > if the UA... if the PUA change its media capability, or=20 > change its status, it MUST refresh the presence document.=20 >=20 >=20 > the upload must be made through the protocol sip!!!=20 > and not push the presence doc via another protocol, such as HTTP = POST.=20 >=20 >=20 > I agree with Steven Donovan when he says in the draft=20 > "Requirement for Pubblication of SIP related service data"=20 > : "... it is felt that the SIP REGISTER request is NOT the=20 > appropriate mechanisme for handing this loading od SIP=20 > service information..." but i'm not sure that a=20 > generalization of the REGISTER function, as proposed in the=20 > draft, is a good idea=20 >=20 >=20 > The use of the method REGISTER, for the upload,introduces one=20 > series of problems, just one example: the expiration of the=20 > Presence document and the expiration of the current=20 > communication addresses (i.e. Contact Addres) are different...=20 >=20 > I have instead a proposed other:=20 > the use of method NOTIFY...=20 > this method is already used for send the presence state to=20 > a particular subscriber...=20 > the its generalization for the upload or refresh of Presence=20 > Document is very simple and has the advantage of not=20 > modify/generalization a very important message for sip as REGISTER... = >=20 >=20 > which is your opinion ?=20 > _______________________________________________=20 > simple mailing list=20 > simple@mailman.dynamicsoft.com=20 > http://mailman.dynamicsoft.com/mailman/listinf > o/simple=20 >=20 _______________________________________________=20 simple mailing list=20 simple@mailman.dynamicsoft.com=20 http://mailman.dynamicsoft.com/mailman/listinfo/simple =20 ------_=_NextPart_001_01C163EA.C5EC2850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] problem: how upload presence document?
The=20 time for discussing it here is passed. It started = here,
but=20 has moved to the SIPPING working group. We = have
been=20 very careful make sure the requirements for = presence
publication are communicated there, starting with=20
draft-donovan-publish-requirements-00.txt and=20 continuing
through the participation of several members from this=20 group.
 
If you=20 have a vested interest the outcome of that work = and
are=20 not already on the sipping list, go join = it.
(see=20 http://w= ww.ietf.org/html.charters/sipping-charter.html)
Be=20 sure to comment on the donovan draft if you see = something
missing.
 
I notice that its new charter = doesn't explicitly=20 call out
working on the publish mechanism - I'm in the=20 process
of=20 finding out what happened to it.
 
RjS
-----Original Message-----
From: Sriram Parameswar = [mailto:sriramp@nortelnetworks.com]
Sent: Friday, November = 02, 2001=20 3:50 PM
To: 'Robert Sparks'; Brian Stucker; 'H=E5kan = Jonsson'; 'sal';=20 'simple'; 'Steve Donovan'
Subject: RE: [Simple] problem: = how upload=20 presence document?

Robert:
 
Is=20 there a PUBLISH - 200 OK in the works? If so, lets discuss its = merits and=20 de-merits in the SIMPLE list. This will avoid a whole lot = of=20 backwards compatibility issues down the road.
 
Regards,
 
Sriram
__________________________________________ =
Sriram=20 = Parameswar          &n= bsp;  =20 Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563 =
Nortel Networks, Richardson USA  = Email: = sriramp@nortelnetworks.com
-----Original Message-----
From: Robert Sparks=20 [mailto:rsparks@dynamicsoft.com]
Sent: Friday, November = 02, 2001=20 3:26 PM
To: Stucker, Brian [NGB:B621:EXCH]; H=E5kan = Jonsson; 'sal';=20 simple; Steve Donovan
Subject: RE: [Simple] problem: how = upload=20 presence document?

We=20 have as a group identified that it is not a good enough=20 thing.
 
We=20 have a defined mechanism that uses REGISTER for = now,
but we recognize that that is not the proper long term=20 solution.
 
We've=20 explored its shortcomings before, and don't need to do=20 so
here again - they are captured in = Steve Donovan's=20 draft. We were
on the path to taking on defining = a method for publishing = presence
data in SIMPLE when we = realized there was a=20 more general need,
so we've handed that work off to SIP by = way of=20 SIPPING (which finally
officially exists). We will = have an=20 item on our revised agenda to
specify how this mechanism will be used = for=20 presence publication
once its = available.
 
In the meantime, we'll use Register = and work=20 around the warts.
 
RjS 
 
 -----Original=20 Message-----
From: Brian Stucker=20 [mailto:bstucker@nortelnetworks.com]
Sent: Friday, = November 02,=20 2001 2:10 PM
To: H=E5kan Jonsson; 'sal'; simple;=20 sdonovan
Subject: RE: [Simple] problem: how upload = presence=20 document?

Well, REGISTER is already out there and in use, = and=20 there's a lot to be
said to sticking = with=20 something that's already been developed (for CPL) =
to do basically the same thing that we need as a general = mechanism.=20 I
would posit that this alone makes it = a good=20 candidate for a default
mechanism to = upload=20 presence fragments into the network.

Brian

-----Original Message-----
From:=20 H=E5kan Jonsson [mailto:hakan.jonsson@bluelabs.= se]=20
Sent: Friday, November 02, 2001 5:05 AM =
To: 'sal'; simple; sdonovan
Subject: SV:=20 [Simple] problem: how upload presence document?


I think that the letting the PA subscribe to = the PUAs=20 presence document
is a nice approach, = since you=20 can use it as it is. One thing you would
need to=20 add to the NOTIFY is an Expires header and interpret that as = the=20
expiration time for a soft state, to satisfy = the=20 requirements in
draft-donovan..., but I = think that=20 is allowed by the current sip-events
draft.=20

The PUA can manipulate presence information in = a number of=20 ways, which
is good. For presence = documents I=20 don't think we should limit ourselves
to one way,=20 but specifying a mechanism to upload service data using = SIP=20
in general as suggested in Donovan's draft is = desirable,=20 and should be
one of the ways to upload = presence=20 documents.

As Donovan suggests in his draft, the actions = to be taken=20 using the
uploaded data could be put in = the body=20 or in an extension of SIP
methods, = headers etc. I=20 think defining a new event type for each type of
data would result in a lot of event types. Using NOTIFY, = SUBSCRIBE=20 with
one new event type: servicedata, = and letting=20 the actual body contain the
specific = data=20 manipulation actions to be done in a service specific =
language, is the most general and clear-cut way to do = it. On the=20 other
hand, if there only a few service = data types=20 needed, we could define
specific event = types for=20 these. Donovan mentions presence documents and
CPL=20 scripts; what other types are needed?

H=E5kan
-----------------=20
H=E5kan=20 = Jonsson           = ;  =20 Drottninggatan 18
BlueLabs South=20 AB          21189=20 Malm=F6
http://www.bluelabs.se    =20 Sweden


> -----Ursprungligt meddelande----- =
> Fr=E5n: simple-admin@mailman.dynamicsoft.com =
> [mailto:simple-admin= @mailman.dynamicsoft.com]=20 F=F6r sal
> Skickat: den 2 november = 2001=20 11:00
> Till: ndeason@ubiquity.net;=20 sdonovan@dynamicsoft.com;
>=20 jdrosen@dynamicsoft.com; dean.willis@softarmor.com =
> Kopia: simple@mailman.dynamicsoft.com =
> =C4mne: [Simple] problem: how upload presence = document?=20
>
> =
> i think that this question: "upload presence = document" is a=20
> critical issue.
>=20
> there isn't a standard procedure = to upload=20 and to modify the
> presence = document, but it=20 is the source of the presence status ...
> if=20 the UA... if the PUA change its media capability, or =
> change its status, it MUST refresh the presence=20 document.
>
>=20
> the upload must be made through = the protocol=20 sip!!!
> and not push the presence = doc via=20 another protocol, such as HTTP POST.
>=20
>
> I = agree with=20 Steven Donovan when he says in the draft
>=20 "Requirement for Pubblication of SIP related service data" =
> : "... it is felt that the SIP REGISTER = request is=20 NOT the
> appropriate mechanisme for = handing=20 this loading od SIP
> service = information..."=20 but i'm not sure that a
> = generalization of the=20 REGISTER function, as proposed in the
> draft,=20 is a good idea
>
>=20
> The use of the method REGISTER, = for the=20 upload,introduces one
> series of = problems,=20 just one example: the expiration of the
>=20 Presence document and the expiration of the current =
> communication addresses (i.e. Contact Addres) are=20 different...
>
> I=20 have instead a proposed other:
> the = use of=20 method NOTIFY...
> this method is = already used=20 for send the presence state to
> a = particular=20 subscriber...
> the its = generalization for the=20 upload or refresh of Presence
> = Document is=20 very simple and has the advantage of not
>=20 modify/generalization a very important message for sip as=20 REGISTER...
>
>=20
> which is your opinion ? =
> = _______________________________________________=20
> simple mailing list
>=20 simple@mailman.dynamicsoft.com
> http://mailman.dynamicsoft.com/mailman/listinf>=20 o/simple
>

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

------_=_NextPart_001_01C163EA.C5EC2850-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 17:14:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20101 for ; Fri, 2 Nov 2001 17:14:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2MBWb7008998; Fri, 2 Nov 2001 17:11:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23001; Fri, 2 Nov 2001 17:13:04 -0500 (EST) 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 RAA22990 for ; Fri, 2 Nov 2001 17:12:34 -0500 (EST) 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 fA2MB1b7008989 for ; Fri, 2 Nov 2001 17:11:01 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 17:12:16 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E754@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks 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] Simple working plan 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, 2 Nov 2001 17:12:10 -0500 Greetings! We have a month to go before IETF52, and need to make optimal use of this time. Here's where we are: * We have the presence draft mostly done. There are two big issues remaining: - whether to immediately NOTIFY a 202 - what to specify about subscription migration * We have the page mode MESSAGE draft ready to hand to SIP. (There has been some nit feedback that Ben will incorporate soon.) This handoff has been in the works since London - it's been caught up in the SIP/SIPPING/SIMPLE rechartering efforts. All of the issues have been worked out, and we're only waiting for the process to play out. Once the new charters are in place, the current message draft will be resubmitted as a SIP WG item. * We have the watcherinfo package definition mostly done. * We have consensus that we should define message sessions. We do not have consensus on how to acheive them. There have been two useful developments on this front recently: - Allison is working with Jon to put together a requirements draft concretely capturing the IESGs concerns. - A group is pulling together to draft a concrete proposal. Given this state, here's how we are going to proceed: 1. We will concentrate on finishing the presence draft. This is our highest priority for the next several days. 2. Once presence is done, we will finish the watcherinfo package. 3. The discussion of message sessions is now tabled. We will return to it when we have Allison's requrements draft, a draft with a concrete proposal, AND we have completed the presence and watcherinfo work. Lets keep the conversation focused and get these tasks done! RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 2 17:25:37 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20374 for ; Fri, 2 Nov 2001 17:25:37 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2MMWb7009155; Fri, 2 Nov 2001 17:22:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23053; Fri, 2 Nov 2001 17:24:04 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23042 for ; Fri, 2 Nov 2001 17:23:40 -0500 (EST) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GM700FA926YJH@firewall.wcom.com> for simple@mailman.dynamicsoft.com; Fri, 2 Nov 2001 22:23:22 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0GM70070126TY6@pmismtp03.wcomnet.com>; Fri, 02 Nov 2001 22:23:22 +0000 (GMT) Received: from omzexch007.mcit.com ([166.37.194.38]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0GM70072B26JG8@pmismtp03.wcomnet.com>; Fri, 02 Nov 2001 22:23:07 +0000 (GMT) Received: by omzexch007 with Internet Mail Service (5.5.2653.19) id ; Fri, 02 Nov 2001 22:23:07 +0000 Content-return: allowed From: "Ngo, Dai (c)" Subject: RE: [Simple] Simple working plan To: "'Robert Sparks'" , "'simple@mailman.dynamicsoft.com'" Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E70@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Fri, 02 Nov 2001 22:23:05 +0000 I like to see the revision of SIP event mentioned somewhere. (=: -- Dai Ngo > >-----Original Message----- > >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >Sent: Friday, November 02, 2001 4:12 PM > >To: 'simple@mailman.dynamicsoft.com' > >Subject: [Simple] Simple working plan > > > >Greetings! > > > >We have a month to go before IETF52, and > >need to make optimal use of this time. > > > >Here's where we are: > > > >* We have the presence draft mostly done. There > > are two big issues remaining: > > - whether to immediately NOTIFY a 202 > > - what to specify about subscription migration > > > >* We have the page mode MESSAGE draft ready to > > hand to SIP. (There has been some nit feedback > > that Ben will incorporate soon.) This handoff > > has been in the works since London - it's been > > caught up in the SIP/SIPPING/SIMPLE rechartering > > efforts. All of the issues have been worked out, > > and we're only waiting for the process to play out. > > Once the new charters are in place, the current > > message draft will be resubmitted as a SIP WG item. > > > >* We have the watcherinfo package definition > > mostly done. > > > >* We have consensus that we should define message > > sessions. We do not have consensus on how to > > acheive them. There have been two useful developments > > on this front recently: > > - Allison is working with Jon to put together a > > requirements draft concretely capturing the IESGs > > concerns. > > - A group is pulling together to draft a concrete > > proposal. > > > >Given this state, here's how we are going to proceed: > > > >1. We will concentrate on finishing the presence draft. > > This is our highest priority for the next several days. > > > >2. Once presence is done, we will finish the watcherinfo package. > > > >3. The discussion of message sessions is now tabled. > > We will return to it when we have Allison's requrements draft, > > a draft with a concrete proposal, AND we have completed > > the presence and watcherinfo work. > > > >Lets keep the conversation focused and get these tasks done! > > > >RjS > > > >_______________________________________________ > >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 Fri Nov 2 17:33:16 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20547 for ; Fri, 2 Nov 2001 17:33:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA2MUYb7009296; Fri, 2 Nov 2001 17:30:34 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23118; Fri, 2 Nov 2001 17:32:04 -0500 (EST) 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 RAA23106 for ; Fri, 2 Nov 2001 17:31:09 -0500 (EST) 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 fA2MTab7009280 for ; Fri, 2 Nov 2001 17:29:36 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 2 Nov 2001 17:30:52 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E757@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Simple working plan 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: Fri, 2 Nov 2001 17:30:48 -0500 That's officially a SIP working group item. > -----Original Message----- > From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] > Sent: Friday, November 02, 2001 4:23 PM > To: 'Robert Sparks'; 'simple@mailman.dynamicsoft.com' > Subject: RE: [Simple] Simple working plan > > > I like to see the revision of SIP event mentioned somewhere. (=: > > -- Dai Ngo _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 6 00:17:37 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16777 for ; Tue, 6 Nov 2001 00:17:36 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA65B1VW007104; Tue, 6 Nov 2001 00:11:02 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03802; Tue, 6 Nov 2001 00:12:20 -0500 (EST) 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 AAA03791 for ; Tue, 6 Nov 2001 00:11:04 -0500 (EST) 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 fA659LVW007089; Tue, 6 Nov 2001 00:09:21 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 00:10:38 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , "Moran Tim (NET/Dallas)" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , James Undery , "'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: 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, 6 Nov 2001 00:10:29 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 1:52 PM To: Brian Stucker; Moran Tim (NET/Dallas); Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 >Forking interactions, for one. The NOTIFY is used to clear out the subscriptions that may >have been created on nodes that the SUBSCRIBE got forked to, but whose response was not >forwarded back to the UAC that sent the original SUBSCRIBE. > This is an excellent point. I have been on the fence about NOTIFY after 202, but am now convinced that a PA sends a NOTIFY immediately after the 202, and that this NOTIFY has no body. >The three-way handshake is in the events draft, and it works. The only issue that I can see >are getting the presence and watcherinfo drafts on board with what the events draft has set >forth, and just clarifying the text in the events draft a little. It's not a big change in >my view. The sip-events draft is due out shortly; I will align presence with it when that happens. Unfortunately, there are still issues with forking. Consider this case: A subscribes to B. It forks, and hits two PA, B1 and B2. B1 responds with a 202 first. This hits the proxy, which forwards the 202 upstream. B2 then responds with a 200, which is absorbed at the proxy. A gets the 202, which establishes tags for the subscription. Next, it gets a NOTIFY from B2, but its rejected, since the tags don't match. Then, its subscription is rejected at B1, which sends a NOTIFY indicating such. As a result, no subscriptions are established at all, even though B2 did allow it. The problem is really this; unless each PA is identical, in terms of its presence state and authorization policies, forking is going to interact badly with it. The reason is rooted in the fact that the subscriber is supposed to reject all NOTIFY's except the one matching the 2xx thats returned. I have long advocated this, since I think presence composition belogns on the presentity side, not the watcher side. However, if there is forking, this means, by definition, that there is no presentity-side composition function. So, my proposal is the following: * there can be multiple PUA for a presentity, of course. If any of them can act as presence agents for the subset of presence data they know of, they can register with the presence server indicating that (methods=SUBSCRIBE) * if a presence server is aware of multiple PUA for a presentity, the presence server SHOULD act as a PA (and therefore not fork subscriptions) * a subscriber SHOULD accept all NOTIFY requests generated by a particular subscription (i.e., not reject all but the one matching the 2xx to SUBSCRIBE), and then compose the presence data from each notification into a complete presence document The third bullet above is the big change. It is my hope to avoid forking of subscriptions with the second bullet above, but if they do happen, we are at least prepared for it in a reasonable way with bullet three. Comments? Hopefully I am making some sense... -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: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com] Sent: Thursday, November 01, 2001 11:36 AM To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan'; adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 To me the term Pending (as in 202 Pending) says hold on I can not answer right now. Sorry, but I just don't see the justification in the immediate dummy message to the receiver of the 202. I understand (think I do) that the empty Notify request is sent so that the notifier can know that the 202 was received because it causes a 200 from Subscriber to Notifier. 4 messages to do a 3 way handshake. It would appear the assumption is that 3-way handshake is required. What is wrong with the subscriber timing out on receiving a response from the notifer (200 or 202) and resending the subscribe? That is, what is wrong with a two-way handshake with a timer? Tim M. -----Original Message----- From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 01, 2001 10:49 AM To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 The wording there can be taken several ways, and probably needs to be clarified. We really need to be talking about two notifications at the point at which a pending subscription comes in: notifying the client that has a event-package.winfo subscription, and notifying the client that is requesting the new event-package subscription (where in this case, event-package is likely to be "presence"). I would argue that you should send an empty NOTIFY to the "presence" subscription, and send a NOTIFY to the "presence.winfo" subscriber telling them that the subscription is waiting for their authorization. If the subscription is a refresh of the pending "presence" subscription, then you need to send an empty NOTIFY to the "presence" subscription, but it's a MAY notify on the "presence.winfo" side (the renotification may not be particularly useful). I think the new version of the events draft is supposed to be sent out today, so maybe that'll provide more clarification. Thoughts? Regards, Brian Stucker -----Original Message----- From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] Sent: Thursday, November 01, 2001 10:27 AM To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg Cc: simple Subject: RE: [Simple] 200 vs. 202 While reviewing the draft "draft-ietf-simple-winfo-package-00.txt" in the section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. *No notifications are generated*, but the subscription FSM is maintained." It seems to me that the above statement contradicts with what we are saying here, that an empty notification is needed to complete the three-ways handshake. How do we reconcile this conflict? -- Dai _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 6 04:37:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04715 for ; Tue, 6 Nov 2001 04:37:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA69UeVW007891; Tue, 6 Nov 2001 04:30:40 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04669; Tue, 6 Nov 2001 04:32:04 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04658 for ; Tue, 6 Nov 2001 04:31:30 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fA69VCT05807; Tue, 6 Nov 2001 10:31:12 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id KAA04408; Tue, 6 Nov 2001 10:31:11 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xmaa03754; Tue, 6 Nov 01 10:30:29 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 10:30:27 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg'" Cc: simple Subject: AW: [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, 6 Nov 2001 10:30:24 +0100 Hello, comments inline. > > * there can be multiple PUA for a presentity, of course. If > any of them can > act as presence agents for the subset of presence data they > know of, they > can register with the presence server indicating that > (methods=SUBSCRIBE) > Agreed. > * if a presence server is aware of multiple PUA for a presentity, the > presence server SHOULD act as a PA (and therefore not fork > subscriptions) So, when I register with the presence server (method=SUBSCRIBE), I can't be sure to be the only one, whitch would mean I don't know if my PA or the presence server "PA" will handle the SUBSCRIBE requests. I'm not sure if this would be a problem. Any thoughts? Wouldn't it make sense to fork and wait for all responses? Then the presence server could be sure to forward the right response. You can always set a timer, to handle missing responses as errors. > * a subscriber SHOULD accept all NOTIFY requests generated > by a particular > subscription (i.e., not reject all but the one matching the 2xx to > SUBSCRIBE), and then compose the presence data from each > notification into a > complete presence document Agreed, because: Think of the situation, when a proxy forks the SUBSCRIBE request to B1 and B2. Lets say both awnser with a 200 Ok followed with an immediate NOTIFY. The proxy might drop one 200 Ok, still you have 2 NOTIFY's on the line. You can only reject a NOTIFY from B2, when you received a 200 Ok from B1. If the NOTIFY from B2 was quicker than the 200 Ok from B1, you need to wait for the 200 Ok (SUBSCRIBE) before responding to the first NOTIFY. After a while you will get a NOTIFY from B1. It's even worse, when the NOTIFY from B1 overtakes it's 200 Ok. Disagreed, because: If you accept all NOTIFY's, you MUST be absolutely sure, they contain the same presence status. Otherwise you might run into inconsistent presence data, which you can't solve (B1 is online, B2 is going for a coffee, etc.) The solution with accepting only one NOTIFY was nice, because you didn't need to worry. It's just simpler. If I missed something, sorry and please tell me! Cu Lachlan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 6 10:00:06 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15963 for ; Tue, 6 Nov 2001 10:00:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA6ErbVW009187; Tue, 6 Nov 2001 09:53:37 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05696; Tue, 6 Nov 2001 09:55:05 -0500 (EST) 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 JAA05682 for ; Tue, 6 Nov 2001 09:54:09 -0500 (EST) 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 fA6Em7VW009118; Tue, 6 Nov 2001 09:48:07 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 09:49:25 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E76C@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'Brian Stucker'" , "Moran Tim (NET/Dallas)" , "Ngo, Dai (c)" , "'Brazier Lachlan'" , "adam.roach" , James Undery , "'ext Paul Kyzivat'" Cc: simple 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, 6 Nov 2001 09:49:15 -0500 inline > So, my proposal is the following: > > * there can be multiple PUA for a presentity, of course. If > any of them can > act as presence agents for the subset of presence data they > know of, they > can register with the presence server indicating that > (methods=SUBSCRIBE) > > * if a presence server is aware of multiple PUA for a presentity, the > presence server SHOULD act as a PA (and therefore not fork > subscriptions) Proxies will fork SUBSCRIBEs - most of those won't happen to also be presence servers. > > * a subscriber SHOULD accept all NOTIFY requests generated > by a particular > subscription (i.e., not reject all but the one matching the 2xx to > SUBSCRIBE), and then compose the presence data from each > notification into a > complete presence document This will cause the composed document to be different before and after the first refresh (RR will prevent all but the notifier whos 2xx we received from being refreshed). > > > The third bullet above is the big change. It is my hope to > avoid forking of > subscriptions with the second bullet above, but if they do > happen, we are at > least prepared for it in a reasonable way with bullet three. > > Comments? Hopefully I am making some sense... > > -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: Moran Tim (NET/Dallas) [mailto:Tim.Moran@nokia.com] > Sent: Thursday, November 01, 2001 11:36 AM > To: Stucker, Brian [NGB:B621:EXCH]; Ngo, Dai (c); 'Brazier Lachlan'; > adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > To me the term Pending (as in 202 Pending) says hold on I can > not answer > right now. Sorry, but I just don't see the justification in > the immediate > dummy message to the receiver of the 202. I understand (think > I do) that the > empty Notify request is sent so that the notifier can know > that the 202 was > received because it causes a 200 from Subscriber to Notifier. > 4 messages to > do a 3 way handshake. > It would appear the assumption is that 3-way handshake is > required. What is > wrong with the subscriber timing out on receiving a response from the > notifer (200 or 202) and resending the subscribe? That is, > what is wrong > with a two-way handshake with a timer? > Tim M. > -----Original Message----- > From: ext Brian Stucker [mailto:bstucker@nortelnetworks.com] > Sent: Thursday, November 01, 2001 10:49 AM > To: Ngo, Dai (c); 'Brazier Lachlan'; Moran Tim (NET/Dallas); > adam.roach; > James Undery; 'ext Paul Kyzivat'; Jonathan Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > The wording there can be taken several ways, and probably needs to be > clarified. We really need to be talking about two > notifications at the point > at which a pending subscription comes in: notifying the > client that has a > event-package.winfo subscription, and notifying the client that is > requesting the new event-package subscription (where in this case, > event-package is likely to be "presence"). > I would argue that you should send an empty NOTIFY to the "presence" > subscription, and send a NOTIFY to the "presence.winfo" > subscriber telling > them that the subscription is waiting for their authorization. If the > subscription is a refresh of the pending "presence" > subscription, then you > need to send an empty NOTIFY to the "presence" subscription, > but it's a MAY > notify on the "presence.winfo" side (the renotification may not be > particularly useful). > > > I think the new version of the events draft is supposed to be sent out > today, so maybe that'll provide more clarification. > Thoughts? > Regards, > Brian Stucker > -----Original Message----- > From: Ngo, Dai (c) [mailto:c-Dai.Ngo@WCOM.Com] > Sent: Thursday, November 01, 2001 10:27 AM > To: Stucker, Brian [NGB:B621:EXCH]; 'Brazier Lachlan'; Moran Tim > (NET/Dallas); adam.roach; James Undery; 'ext Paul Kyzivat'; Jonathan > Rosenberg > Cc: simple > Subject: RE: [Simple] 200 vs. 202 > > > While reviewing the draft > "draft-ietf-simple-winfo-package-00.txt" in the > section 3.6.1 "The Watcherinfo State Machine" it says, "If, when a > subscription arrives, there is no authorization policy in > existence, the > subscription moves into the pending state. In this state, the > server is > awaiting an authorization decision. *No notifications are > generated*, but > the subscription FSM is maintained." > It seems to me that the above statement contradicts with what > we are saying > here, that an empty notification is needed to complete the three-ways > handshake. > > How do we reconcile this conflict? > > -- Dai > > > > _______________________________________________ > 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 Tue Nov 6 10:03:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16251 for ; Tue, 6 Nov 2001 10:03:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA6EuUVW009266; Tue, 6 Nov 2001 09:56:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05788; Tue, 6 Nov 2001 09:58:06 -0500 (EST) 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 JAA05748 for ; Tue, 6 Nov 2001 09:57:24 -0500 (EST) 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 fA6EtmVW009262 for ; Tue, 6 Nov 2001 09:55:48 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 09:57:06 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E76D@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks 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] Closure : Notification after 2xx 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, 6 Nov 2001 09:57:00 -0500 After reviewing the thread, I believe this to be our consensus: A SUBSCRIBE for Event:presence can be answered with either a 200 or a 202. 200 means conclusively that the subscription was granted. A 2xx response will _always_ be followed immediately by a NOTIFY. For 202ed SUBSCRIBEs, the NOTIFY SHOULD be empty, but MAY contain a "neutral" presence document if such a thing exists for that resource. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 6 10:56:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19026 for ; Tue, 6 Nov 2001 10:56:16 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA6FrUVW009966; Tue, 6 Nov 2001 10:53:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06182; Tue, 6 Nov 2001 10:55:05 -0500 (EST) 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 KAA06168 for ; Tue, 6 Nov 2001 10:54:19 -0500 (EST) 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 fA6FjKVW009875; Tue, 6 Nov 2001 10:45:20 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 10:46:39 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E76F@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'James Undery'" , Robert Sparks , Jonathan Rosenberg , "'Brian Stucker'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" Cc: "'simple'" 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, 6 Nov 2001 10:46:35 -0500 > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > by a particular > > > subscription (i.e., not reject all but the one matching the 2xx to > > > SUBSCRIBE), and then compose the presence data from each > > > notification into a > > > complete presence document > > > > This will cause the composed document to be different before > > and after the first refresh (RR will prevent all but the > > notifier whos 2xx we received from being refreshed). > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > follow the > route set created from the SUBSCRIBE(?!), all proxies wishing > to record > route will get the opportunity to add a record route header > to the NOTIFY as > per normal. The problem is not with the NOTIFY, its with the reSUBSCRIBE that will refresh the subscription. That request will get to exactly one of the notifiers. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 6 11:06:06 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19374 for ; Tue, 6 Nov 2001 11:06:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA6G3TVW010122; Tue, 6 Nov 2001 11:03:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06306; Tue, 6 Nov 2001 11:05:05 -0500 (EST) 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 LAA06277 for ; Tue, 6 Nov 2001 11:04:14 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [63.113.40.50]) with SMTP; 6 Nov 2001 16:04:03 UT Received: from gbnewp0796m ([193.195.52.113]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 6 Nov 2001 16:06:15 +0000 From: "James Undery" To: "'Robert Sparks'" , "'Jonathan Rosenberg'" , "'Brian Stucker'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" Cc: "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <005501c166dc$f62cbd50$7134c3c1@eu.ubiquity.net> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E76F@DYN-TX-EXCH-001.dynamicsoft.com> Importance: Normal X-OriginalArrivalTime: 06 Nov 2001 16:06:15.0332 (UTC) FILETIME=[F6401E40:01C166DC] 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, 6 Nov 2001 16:06:14 -0000 Content-Transfer-Encoding: 7bit > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > by a particular > > > > subscription (i.e., not reject all but the one matching > the 2xx to > > > > SUBSCRIBE), and then compose the presence data from each > > > > notification into a > > > > complete presence document > > > > > > This will cause the composed document to be different before > > > and after the first refresh (RR will prevent all but the > > > notifier whos 2xx we received from being refreshed). > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > follow the > > route set created from the SUBSCRIBE(?!), all proxies wishing > > to record > > route will get the opportunity to add a record route header > > to the NOTIFY as > > per normal. > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > that will refresh the subscription. That request will get to > exactly one of the notifiers. Well that's what I missed, I assumed each subscription would be refreshed individually following the route-set (which at a minimum should be the contact for that subscription). James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 6 21:42:08 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09528 for ; Tue, 6 Nov 2001 21:42:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA72dfVW014803; Tue, 6 Nov 2001 21:39:41 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08453; Tue, 6 Nov 2001 21:41:05 -0500 (EST) 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 VAA08437 for ; Tue, 6 Nov 2001 21:39:47 -0500 (EST) 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 UAA04156 for ; Tue, 6 Nov 2001 20:39:23 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 6 Nov 2001 20:36:21 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 6 Nov 2001 20:38:24 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EB92037@zrc2c012.us.nortel.com> From: "Brian Stucker" To: James Undery , "'Robert Sparks'" , "'Jonathan Rosenberg'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" 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_01C16735.43FB6100" 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, 6 Nov 2001 20:38:21 -0600 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_01C16735.43FB6100 Content-Type: text/plain; charset="iso-8859-1" So, we're back to the original, needs to be clarified text in the draft. 4 message, 3-way handshake... correct? Brian -----Original Message----- From: James Undery [mailto:jundery@ubiquity.net] Sent: Tuesday, November 06, 2001 10:06 AM To: 'Robert Sparks'; 'Jonathan Rosenberg'; Stucker, Brian [NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > by a particular > > > > subscription (i.e., not reject all but the one matching > the 2xx to > > > > SUBSCRIBE), and then compose the presence data from each > > > > notification into a > > > > complete presence document > > > > > > This will cause the composed document to be different before > > > and after the first refresh (RR will prevent all but the > > > notifier whos 2xx we received from being refreshed). > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > follow the > > route set created from the SUBSCRIBE(?!), all proxies wishing > > to record > > route will get the opportunity to add a record route header > > to the NOTIFY as > > per normal. > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > that will refresh the subscription. That request will get to > exactly one of the notifiers. Well that's what I missed, I assumed each subscription would be refreshed individually following the route-set (which at a minimum should be the contact for that subscription). James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C16735.43FB6100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

So, we're back to the original, needs to be clarified = text in the draft.

4 message, 3-way handshake... correct?

Brian

-----Original Message-----
From: James Undery [mailto:jundery@ubiquity.net]
Sent: Tuesday, November 06, 2001 10:06 AM
To: 'Robert Sparks'; 'Jonathan Rosenberg'; Stucker, = Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai = (c)'; 'Brazier
Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202


> > > >  * a subscriber SHOULD = accept all NOTIFY requests generated
> > > > by a particular
> > > > subscription (i.e., not reject = all but the one matching
> the 2xx to
> > > > SUBSCRIBE), and then compose the = presence data from each
> > > > notification into a
> > > > complete presence = document
> > >
> > > This will cause the composed document = to be different before
> > > and after the first refresh (RR will = prevent all but the
> > > notifier whos 2xx we received from = being refreshed).
> >
> > Sorry, I am a bit slow and can't see why = not. The NOTIFY will
> > follow the
> > route set created from the SUBSCRIBE(?!), = all proxies wishing
> > to record
> > route will get the opportunity to add a = record route header
> > to the NOTIFY as
> > per normal.
>
> The problem is not with the NOTIFY, its with = the reSUBSCRIBE
> that will refresh the subscription. That = request will get to
> exactly one of the notifiers.

Well that's what I missed, I assumed each = subscription would be refreshed
individually following the route-set (which at a = minimum should be the
contact for that subscription).

James

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

------_=_NextPart_001_01C16735.43FB6100-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 7 03:00:07 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29042 for ; Wed, 7 Nov 2001 03:00:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA77vkVW015721; Wed, 7 Nov 2001 02:57:46 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09433; Wed, 7 Nov 2001 02:59:05 -0500 (EST) 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 CAA09422 for ; Wed, 7 Nov 2001 02:58:36 -0500 (EST) 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 fA77utVW015713; Wed, 7 Nov 2001 02:56:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 02:58:13 -0500 Message-ID: From: Jonathan Rosenberg To: "'James Undery'" , Robert Sparks , Jonathan Rosenberg , "'Brian Stucker'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" Cc: "'simple'" 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: Wed, 7 Nov 2001 02:58:06 -0500 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, November 06, 2001 11:06 AM > To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim > (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext > Paul Kyzivat' > Cc: 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > > by a particular > > > > > subscription (i.e., not reject all but the one matching > > the 2xx to > > > > > SUBSCRIBE), and then compose the presence data from each > > > > > notification into a > > > > > complete presence document > > > > > > > > This will cause the composed document to be different before > > > > and after the first refresh (RR will prevent all but the > > > > notifier whos 2xx we received from being refreshed). > > > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > > follow the > > > route set created from the SUBSCRIBE(?!), all proxies wishing > > > to record > > > route will get the opportunity to add a record route header > > > to the NOTIFY as > > > per normal. > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Well that's what I missed, I assumed each subscription would > be refreshed > individually following the route-set (which at a minimum should be the > contact for that subscription). That was my assumption as well. If you accept more than one NOTIFY, you really have to refresh each individual subscription. The watcher would then need to continue to compose aggregated presence documents throughout the lifetime of the subscriptions. Again, I prefer that the watcher not have to do that, but since I can't guarantee that there won't be forking proxies, there doesn't seem to be a clean way to get around it. -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 Nov 7 03:05:14 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29078 for ; Wed, 7 Nov 2001 03:05:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA782TVW015789; Wed, 7 Nov 2001 03:02:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09468; Wed, 7 Nov 2001 03:04:05 -0500 (EST) 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 DAA09457 for ; Wed, 7 Nov 2001 03:03:31 -0500 (EST) 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 fA781tVW015785; Wed, 7 Nov 2001 03:01:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 03:03:13 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brazier Lachlan'" , 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: 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, 7 Nov 2001 03:03:03 -0500 > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Tuesday, November 06, 2001 4:30 AM > To: 'Jonathan Rosenberg' > Cc: simple > Subject: AW: [Simple] 200 vs. 202 > > > > * if a presence server is aware of multiple PUA for a > presentity, the > > presence server SHOULD act as a PA (and therefore not fork > > subscriptions) > > So, when I register with the presence server > (method=SUBSCRIBE), I can't be methods=SUBSCRIBE (plural) > sure to be the only one, whitch would mean I don't know if my > PA or the > presence server "PA" will handle the SUBSCRIBE requests. I'm > not sure if > this would be a problem. Any thoughts? Its not a problem at all. In fact, it could very well be BOTH. The presence server acts as a PA, but to get at your presence state, it SUBSCRIBEs to your PUA. > > Wouldn't it make sense to fork and wait for all responses? Proxy forking behavior doesn't work this way. In any case, its irrelevant, since the issue is with whether or not the notifications are accepted at the subscriber. > > * a subscriber SHOULD accept all NOTIFY requests generated > > by a particular > > subscription (i.e., not reject all but the one matching the 2xx to > > SUBSCRIBE), and then compose the presence data from each > > notification into a > > complete presence document > > > Disagreed, because: > If you accept all NOTIFY's, you MUST be absolutely sure, they > contain the > same presence status. No, that is not true at all. The most common case is that they contain non-overlapping presence status. That is, someone subscribes to jdrosen@dynamicsoft.com, and that forks to my PC and my cell phone. Each generate independent pieces of presence for jdrosen, which are combined at the subscriber. -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 Nov 7 04:37:53 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29916 for ; Wed, 7 Nov 2001 04:37:52 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA79ZUVW016074; Wed, 7 Nov 2001 04:35:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09798; Wed, 7 Nov 2001 04:37:05 -0500 (EST) 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 EAA09787 for ; Wed, 7 Nov 2001 04:36:48 -0500 (EST) 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 DAA01896 for ; Wed, 7 Nov 2001 03:36:25 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 7 Nov 2001 03:29:23 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 03:35:22 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EB920E0@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , "'James Undery'" , Robert Sparks , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" 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_01C1676F.85B02970" 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, 7 Nov 2001 03:35:22 -0600 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_01C1676F.85B02970 Content-Type: text/plain; charset="iso-8859-1" Seems dangerous to allow the watcher to take NOTIFY messages that it didn't get the 2xx response for. What is the watcher going to do if the notifications that it receives don't mesh, ie.: - one PA says a contact is online, the other says it's offline? - a PA says the subscription is pending, and is an aggregator of the PUA's, but another PA says the subscription is active, and is not an aggregator? I think you need to have some sort of order of precedence for the watcher to be able to process the notifications correctly. Before your order of precedence rules were pretty simple: if the tags match, take it, otherwise don't. Now, you've opened yourself up to all sorts of new complexities. Hmmm... There's got to be a better way... Regards, Brian Stucker Nortel Networks -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 07, 2001 1:58 AM To: 'James Undery'; Robert Sparks; Jonathan Rosenberg; Stucker, Brian [NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, November 06, 2001 11:06 AM > To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim > (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext > Paul Kyzivat' > Cc: 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > > by a particular > > > > > subscription (i.e., not reject all but the one matching > > the 2xx to > > > > > SUBSCRIBE), and then compose the presence data from each > > > > > notification into a > > > > > complete presence document > > > > > > > > This will cause the composed document to be different before > > > > and after the first refresh (RR will prevent all but the > > > > notifier whos 2xx we received from being refreshed). > > > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > > follow the > > > route set created from the SUBSCRIBE(?!), all proxies wishing > > > to record > > > route will get the opportunity to add a record route header > > > to the NOTIFY as > > > per normal. > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Well that's what I missed, I assumed each subscription would > be refreshed > individually following the route-set (which at a minimum should be the > contact for that subscription). That was my assumption as well. If you accept more than one NOTIFY, you really have to refresh each individual subscription. The watcher would then need to continue to compose aggregated presence documents throughout the lifetime of the subscriptions. Again, I prefer that the watcher not have to do that, but since I can't guarantee that there won't be forking proxies, there doesn't seem to be a clean way to get around it. -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 ------_=_NextPart_001_01C1676F.85B02970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Seems dangerous to allow the watcher to take NOTIFY = messages that it didn't get the 2xx response for. What is the watcher = going to do if the notifications that it receives don't mesh, = ie.:

- one PA says a contact is online, the other says = it's offline?
- a PA says the subscription is pending, and is an = aggregator of the PUA's, but another PA says the subscription is = active, and is not an aggregator?


I think you need to have some sort of order of = precedence for the watcher to be able to process the notifications = correctly. Before your order of precedence rules were pretty simple: if = the tags match, take it, otherwise don't. Now, you've opened yourself = up to all sorts of new complexities.

Hmmm... There's got to be a better way...


Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, November 07, 2001 1:58 AM
To: 'James Undery'; Robert Sparks; Jonathan = Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai = (c)'; 'Brazier
Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202





> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, November 06, 2001 11:06 = AM
> To: 'Robert Sparks'; 'Jonathan Rosenberg'; = 'Brian Stucker'; 'Moran Tim
> (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier = Lachlan'; 'adam.roach'; 'ext
> Paul Kyzivat'
> Cc: 'simple'
> Subject: RE: [Simple] 200 vs. 202
>
>
> > > > >  * a subscriber SHOULD = accept all NOTIFY requests generated
> > > > > by a particular
> > > > > subscription (i.e., not = reject all but the one matching
> > the 2xx to
> > > > > SUBSCRIBE), and then = compose the presence data from each
> > > > > notification into a
> > > > > complete presence = document
> > > >
> > > > This will cause the composed = document to be different before
> > > > and after the first refresh (RR = will prevent all but the
> > > > notifier whos 2xx we received = from being refreshed).
> > >
> > > Sorry, I am a bit slow and can't see = why not. The NOTIFY will
> > > follow the
> > > route set created from the = SUBSCRIBE(?!), all proxies wishing
> > > to record
> > > route will get the opportunity to add = a record route header
> > > to the NOTIFY as
> > > per normal.
> >
> > The problem is not with the NOTIFY, its = with the reSUBSCRIBE
> > that will refresh the subscription. That = request will get to
> > exactly one of the notifiers.
>
> Well that's what I missed, I assumed each = subscription would
> be refreshed
> individually following the route-set (which at = a minimum should be the
> contact for that subscription).

That was my assumption as well. If you accept more = than one NOTIFY, you
really have to refresh each individual subscription. = The watcher would then
need to continue to compose aggregated presence = documents throughout the
lifetime of the subscriptions.

Again, I prefer that the watcher not have to do that, = but since I can't
guarantee that there won't be forking proxies, there = doesn't seem to be a
clean way to get around it.

-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
 

------_=_NextPart_001_01C1676F.85B02970-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 7 09:37:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08400 for ; Wed, 7 Nov 2001 09:37:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA7EYeVW017188; Wed, 7 Nov 2001 09:34:40 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10705; Wed, 7 Nov 2001 09:36:04 -0500 (EST) 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 JAA10694 for ; Wed, 7 Nov 2001 09:35:50 -0500 (EST) 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 fA7EYAVW017179; Wed, 7 Nov 2001 09:34:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 09:35:27 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , Jonathan Rosenberg , "'James Undery'" , Robert Sparks , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" Cc: "'simple'" 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: Wed, 7 Nov 2001 09:35:26 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Wednesday, November 07, 2001 4:35 AM To: Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 >Seems dangerous to allow the watcher to take NOTIFY messages that it didn't get the 2xx >response for. What is the watcher going to do if the notifications that it receives don't >mesh, ie.: >- one PA says a contact is online, the other says it's offline? You shouldn't be receiving presence data for the same contact from two different PUA. In fact, each PUA would generate a presence document with tuples with distinct id's. Since the id's are chosen randomly, you'd have to actively be trying to cause an overlap to occur. >- a PA says the subscription is pending, and is an aggregator of the PUA's, but another PA >says the subscription is active, and is not an aggregator? There would be multiple active subscriptions, one for each PA which generated a NOTIFY. >I think you need to have some sort of order of precedence for the watcher to be able to >process the notifications correctly. Before your order of precedence rules were pretty >simple: if the tags match, take it, otherwise don't. Now, you've opened yourself up to all >sorts of new complexities. All of this is covered under sip-events. I don't see any precedence issues. > >Hmmm... There's got to be a better way... The better way is to have aggregating presence agents. But, since we can't guarantee that, I think this kind of treatment may be needed. -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 --- 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 Nov 7 17:08:13 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24775 for ; Wed, 7 Nov 2001 17:08:13 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA7M5n0r021476; Wed, 7 Nov 2001 17:05:49 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12134; Wed, 7 Nov 2001 17:07:09 -0500 (EST) 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 RAA12122 for ; Wed, 7 Nov 2001 17:06:41 -0500 (EST) 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 QAA04295 for ; Wed, 7 Nov 2001 16:06:16 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 7 Nov 2001 16:02:50 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 16:04:58 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EB92B9A@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , "'James Undery'" , Robert Sparks , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" 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_01C167D8.3BCE57A0" 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, 7 Nov 2001 16:04:55 -0600 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_01C167D8.3BCE57A0 Content-Type: text/plain; charset="iso-8859-1" Has usage of the 3xx class of responses been looked at to help with the SUBSCRIBE forking? Seems like they could be very handy towards this end. Regards, Brian Stucker Nortel Networks -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 07, 2001 1:58 AM To: 'James Undery'; Robert Sparks; Jonathan Rosenberg; Stucker, Brian [NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, November 06, 2001 11:06 AM > To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim > (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext > Paul Kyzivat' > Cc: 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > > by a particular > > > > > subscription (i.e., not reject all but the one matching > > the 2xx to > > > > > SUBSCRIBE), and then compose the presence data from each > > > > > notification into a > > > > > complete presence document > > > > > > > > This will cause the composed document to be different before > > > > and after the first refresh (RR will prevent all but the > > > > notifier whos 2xx we received from being refreshed). > > > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > > follow the > > > route set created from the SUBSCRIBE(?!), all proxies wishing > > > to record > > > route will get the opportunity to add a record route header > > > to the NOTIFY as > > > per normal. > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Well that's what I missed, I assumed each subscription would > be refreshed > individually following the route-set (which at a minimum should be the > contact for that subscription). That was my assumption as well. If you accept more than one NOTIFY, you really have to refresh each individual subscription. The watcher would then need to continue to compose aggregated presence documents throughout the lifetime of the subscriptions. Again, I prefer that the watcher not have to do that, but since I can't guarantee that there won't be forking proxies, there doesn't seem to be a clean way to get around it. -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 ------_=_NextPart_001_01C167D8.3BCE57A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Has usage of the 3xx class of responses been looked = at to help with the SUBSCRIBE forking? Seems like they could be very = handy towards this end.

Regards,

Brian Stucker
Nortel Networks

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, November 07, 2001 1:58 AM
To: 'James Undery'; Robert Sparks; Jonathan = Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai = (c)'; 'Brazier
Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202





> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, November 06, 2001 11:06 = AM
> To: 'Robert Sparks'; 'Jonathan Rosenberg'; = 'Brian Stucker'; 'Moran Tim
> (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier = Lachlan'; 'adam.roach'; 'ext
> Paul Kyzivat'
> Cc: 'simple'
> Subject: RE: [Simple] 200 vs. 202
>
>
> > > > >  * a subscriber SHOULD = accept all NOTIFY requests generated
> > > > > by a particular
> > > > > subscription (i.e., not = reject all but the one matching
> > the 2xx to
> > > > > SUBSCRIBE), and then = compose the presence data from each
> > > > > notification into a
> > > > > complete presence = document
> > > >
> > > > This will cause the composed = document to be different before
> > > > and after the first refresh (RR = will prevent all but the
> > > > notifier whos 2xx we received = from being refreshed).
> > >
> > > Sorry, I am a bit slow and can't see = why not. The NOTIFY will
> > > follow the
> > > route set created from the = SUBSCRIBE(?!), all proxies wishing
> > > to record
> > > route will get the opportunity to add = a record route header
> > > to the NOTIFY as
> > > per normal.
> >
> > The problem is not with the NOTIFY, its = with the reSUBSCRIBE
> > that will refresh the subscription. That = request will get to
> > exactly one of the notifiers.
>
> Well that's what I missed, I assumed each = subscription would
> be refreshed
> individually following the route-set (which at = a minimum should be the
> contact for that subscription).

That was my assumption as well. If you accept more = than one NOTIFY, you
really have to refresh each individual subscription. = The watcher would then
need to continue to compose aggregated presence = documents throughout the
lifetime of the subscriptions.

Again, I prefer that the watcher not have to do that, = but since I can't
guarantee that there won't be forking proxies, there = doesn't seem to be a
clean way to get around it.

-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
 

------_=_NextPart_001_01C167D8.3BCE57A0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 7 17:30:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25073 for ; Wed, 7 Nov 2001 17:30:51 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA7MSU0r021761; Wed, 7 Nov 2001 17:28:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12221; Wed, 7 Nov 2001 17:30:06 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12207 for ; Wed, 7 Nov 2001 17:29:02 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fA7MSgT07566 for ; Wed, 7 Nov 2001 16:28:43 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fA7MSgr20027 for ; Wed, 7 Nov 2001 16:28:42 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Nov 07 16:28:41 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 16:28:41 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'Brian Stucker'" , Jonathan Rosenberg , "'James Undery'" , Robert Sparks , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" 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_01C167DB.8CC62860" 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, 7 Nov 2001 16:28:40 -0600 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_01C167DB.8CC62860 Content-Type: text/plain; charset="iso-8859-1" Should you aggregate the 3xx responses you receive on the branches of the fork(s)? I'm curious what this would look like in a multi-level forking situation. BR, Sean Olson Ericsson Inc. -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Wednesday, November 07, 2001 4:05 PM To: Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 Has usage of the 3xx class of responses been looked at to help with the SUBSCRIBE forking? Seems like they could be very handy towards this end. Regards, Brian Stucker Nortel Networks -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 07, 2001 1:58 AM To: 'James Undery'; Robert Sparks; Jonathan Rosenberg; Stucker, Brian [NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 > -----Original Message----- > From: James Undery [mailto:jundery@ubiquity.net] > Sent: Tuesday, November 06, 2001 11:06 AM > To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim > (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext > Paul Kyzivat' > Cc: 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > > by a particular > > > > > subscription (i.e., not reject all but the one matching > > the 2xx to > > > > > SUBSCRIBE), and then compose the presence data from each > > > > > notification into a > > > > > complete presence document > > > > > > > > This will cause the composed document to be different before > > > > and after the first refresh (RR will prevent all but the > > > > notifier whos 2xx we received from being refreshed). > > > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > > follow the > > > route set created from the SUBSCRIBE(?!), all proxies wishing > > > to record > > > route will get the opportunity to add a record route header > > > to the NOTIFY as > > > per normal. > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Well that's what I missed, I assumed each subscription would > be refreshed > individually following the route-set (which at a minimum should be the > contact for that subscription). That was my assumption as well. If you accept more than one NOTIFY, you really have to refresh each individual subscription. The watcher would then need to continue to compose aggregated presence documents throughout the lifetime of the subscriptions. Again, I prefer that the watcher not have to do that, but since I can't guarantee that there won't be forking proxies, there doesn't seem to be a clean way to get around it. -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 ------_=_NextPart_001_01C167DB.8CC62860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Should you aggregate the 3xx responses you = receive
on the branches of the fork(s)? I'm curious = what
this would look like in a multi-level forking = situation.

BR,
Sean Olson
Ericsson Inc.

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Wednesday, November 07, 2001 4:05 PM
To: Jonathan Rosenberg; 'James Undery'; Robert = Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; = 'adam.roach'; 'ext Paul Kyzivat'

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


Has usage of the 3xx class of responses been looked = at to help with the SUBSCRIBE forking? Seems like they could be very = handy towards this end.

Regards,
Brian Stucker
Nortel Networks
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, November 07, 2001 1:58 AM
To: 'James Undery'; Robert Sparks; Jonathan = Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai = (c)'; 'Brazier
Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202





> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net] =
> Sent: Tuesday, November 06, 2001 11:06 AM =
> To: 'Robert Sparks'; 'Jonathan Rosenberg'; = 'Brian Stucker'; 'Moran Tim
> (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier = Lachlan'; 'adam.roach'; 'ext
> Paul Kyzivat'
> Cc: 'simple'
> Subject: RE: [Simple] 200 vs. 202
>
>
> > > > >  * a subscriber SHOULD = accept all NOTIFY requests generated
> > > > > by a particular
> > > > > subscription (i.e., not = reject all but the one matching
> > the 2xx to
> > > > > SUBSCRIBE), and then = compose the presence data from each
> > > > > notification into a
> > > > > complete presence document =
> > > >
> > > > This will cause the composed = document to be different before
> > > > and after the first refresh (RR = will prevent all but the
> > > > notifier whos 2xx we received = from being refreshed).
> > >
> > > Sorry, I am a bit slow and can't see = why not. The NOTIFY will
> > > follow the
> > > route set created from the = SUBSCRIBE(?!), all proxies wishing
> > > to record
> > > route will get the opportunity to add = a record route header
> > > to the NOTIFY as
> > > per normal.
> >
> > The problem is not with the NOTIFY, its = with the reSUBSCRIBE
> > that will refresh the subscription. That = request will get to
> > exactly one of the notifiers.
>
> Well that's what I missed, I assumed each = subscription would
> be refreshed
> individually following the route-set (which at = a minimum should be the
> contact for that subscription).
That was my assumption as well. If you accept more = than one NOTIFY, you
really have to refresh each individual subscription. = The watcher would then
need to continue to compose aggregated presence = documents throughout the
lifetime of the subscriptions.
Again, I prefer that the watcher not have to do = that, but since I can't
guarantee that there won't be forking proxies, there = doesn't seem to be a
clean way to get around it.
-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
 

------_=_NextPart_001_01C167DB.8CC62860-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 7 17:58:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25499 for ; Wed, 7 Nov 2001 17:58:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA7MuU0r022088; Wed, 7 Nov 2001 17:56:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12321; Wed, 7 Nov 2001 17:58:05 -0500 (EST) 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 RAA12310 for ; Wed, 7 Nov 2001 17:57:33 -0500 (EST) 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 QAA19234 for ; Wed, 7 Nov 2001 16:57:08 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 7 Nov 2001 16:53:52 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 7 Nov 2001 16:56:00 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EB92CA4@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Sean Olson (EUS)" , Jonathan Rosenberg , "'James Undery'" , Robert Sparks , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" 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_01C167DF.5D51BB90" 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, 7 Nov 2001 16:55:58 -0600 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_01C167DF.5D51BB90 Content-Type: text/plain; charset="iso-8859-1" Don't know. I could see a presence aware proxy sending back a 300 with q values in the contact to denote which presence agents likely have the best picture of the user's presence, or a presence server returning a 302 to a SUBSCRIBE due to presence migration. -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Wednesday, November 07, 2001 4:29 PM To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 Should you aggregate the 3xx responses you receive on the branches of the fork(s)? I'm curious what this would look like in a multi-level forking situation. BR, Sean Olson Ericsson Inc. -----Original Message----- From: Brian Stucker [ mailto:bstucker@nortelnetworks.com ] Sent: Wednesday, November 07, 2001 4:05 PM To: Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 Has usage of the 3xx class of responses been looked at to help with the SUBSCRIBE forking? Seems like they could be very handy towards this end. Regards, Brian Stucker Nortel Networks -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Wednesday, November 07, 2001 1:58 AM To: 'James Undery'; Robert Sparks; Jonathan Rosenberg; Stucker, Brian [NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 > -----Original Message----- > From: James Undery [ mailto:jundery@ubiquity.net ] > Sent: Tuesday, November 06, 2001 11:06 AM > To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim > (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext > Paul Kyzivat' > Cc: 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > > > > * a subscriber SHOULD accept all NOTIFY requests generated > > > > > by a particular > > > > > subscription (i.e., not reject all but the one matching > > the 2xx to > > > > > SUBSCRIBE), and then compose the presence data from each > > > > > notification into a > > > > > complete presence document > > > > > > > > This will cause the composed document to be different before > > > > and after the first refresh (RR will prevent all but the > > > > notifier whos 2xx we received from being refreshed). > > > > > > Sorry, I am a bit slow and can't see why not. The NOTIFY will > > > follow the > > > route set created from the SUBSCRIBE(?!), all proxies wishing > > > to record > > > route will get the opportunity to add a record route header > > > to the NOTIFY as > > > per normal. > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Well that's what I missed, I assumed each subscription would > be refreshed > individually following the route-set (which at a minimum should be the > contact for that subscription). That was my assumption as well. If you accept more than one NOTIFY, you really have to refresh each individual subscription. The watcher would then need to continue to compose aggregated presence documents throughout the lifetime of the subscriptions. Again, I prefer that the watcher not have to do that, but since I can't guarantee that there won't be forking proxies, there doesn't seem to be a clean way to get around it. -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 ------_=_NextPart_001_01C167DF.5D51BB90 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] 200 vs. 202
Don't know. I could see a presence aware proxy sending back a 300 with q values in the contact to denote which presence agents likely have the best picture of the user's presence, or a presence server returning a 302 to a SUBSCRIBE due to presence migration.
 
 
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Wednesday, November 07, 2001 4:29 PM
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202

Should you aggregate the 3xx responses you receive
on the branches of the fork(s)? I'm curious what
this would look like in a multi-level forking situation.

BR,
Sean Olson
Ericsson Inc.

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
Sent: Wednesday, November 07, 2001 4:05 PM
To: Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'

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


Has usage of the 3xx class of responses been looked at to help with the SUBSCRIBE forking? Seems like they could be very handy towards this end.

Regards,
Brian Stucker
Nortel Networks
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, November 07, 2001 1:58 AM
To: 'James Undery'; Robert Sparks; Jonathan Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier
Lachlan'; 'adam.roach'; 'ext Paul Kyzivat'
Cc: 'simple'
Subject: RE: [Simple] 200 vs. 202





> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, November 06, 2001 11:06 AM
> To: 'Robert Sparks'; 'Jonathan Rosenberg'; 'Brian Stucker'; 'Moran Tim
> (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext
> Paul Kyzivat'
> Cc: 'simple'
> Subject: RE: [Simple] 200 vs. 202
>
>
> > > > >  * a subscriber SHOULD accept all NOTIFY requests generated
> > > > > by a particular
> > > > > subscription (i.e., not reject all but the one matching
> > the 2xx to
> > > > > SUBSCRIBE), and then compose the presence data from each
> > > > > notification into a
> > > > > complete presence document
> > > >
> > > > This will cause the composed document to be different before
> > > > and after the first refresh (RR will prevent all but the
> > > > notifier whos 2xx we received from being refreshed).
> > >
> > > Sorry, I am a bit slow and can't see why not. The NOTIFY will
> > > follow the
> > > route set created from the SUBSCRIBE(?!), all proxies wishing
> > > to record
> > > route will get the opportunity to add a record route header
> > > to the NOTIFY as
> > > per normal.
> >
> > The problem is not with the NOTIFY, its with the reSUBSCRIBE
> > that will refresh the subscription. That request will get to
> > exactly one of the notifiers.
>
> Well that's what I missed, I assumed each subscription would
> be refreshed
> individually following the route-set (which at a minimum should be the
> contact for that subscription).
That was my assumption as well. If you accept more than one NOTIFY, you
really have to refresh each individual subscription. The watcher would then
need to continue to compose aggregated presence documents throughout the
lifetime of the subscriptions.
Again, I prefer that the watcher not have to do that, but since I can't
guarantee that there won't be forking proxies, there doesn't seem to be a
clean way to get around it.
-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
 

------_=_NextPart_001_01C167DF.5D51BB90-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 7 23:32:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02779 for ; Wed, 7 Nov 2001 23:32:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA84Tj0r023205; Wed, 7 Nov 2001 23:29:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13343; Wed, 7 Nov 2001 23:31:10 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA13332 for ; Wed, 7 Nov 2001 23:30:42 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fA84UNT26099; Thu, 8 Nov 2001 05:30:23 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id FAA10055; Thu, 8 Nov 2001 05:30:21 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma009957; Thu, 8 Nov 01 05:30:11 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Nov 2001 05:30:10 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg '" , "''Brian Stucker' '" , "''James Undery' '" , "'Robert Sparks '" , "''Moran Tim (NET/Dallas)' '" , "''Ngo, Dai (c)' '" , Brazier Lachlan , "''adam.roach' '" , "''ext Paul Kyzivat' '" Cc: "''simple' '" Subject: AW: [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: Thu, 8 Nov 2001 05:30:08 +0100 Hello, Concerning accepting multiple NOTIFY's. I don't like the idea that the subscriber must determine the state of the presentity. I think it's the responsibility of the presentity, to tell the state it is in. Otherwise I really don't believe, that the presentity status can be handled correctly for the reasons mentioned below. Cu Lachlan -----Originalnachricht----- Von: Jonathan Rosenberg An: 'Brian Stucker'; Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Gesendet: 07.11.01 15:35 Betreff: RE: [Simple] 200 vs. 202 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Wednesday, November 07, 2001 4:35 AM To: Jonathan Rosenberg; 'James Undery'; Robert Sparks; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'adam.roach'; 'ext Paul Kyzivat' Cc: 'simple' Subject: RE: [Simple] 200 vs. 202 >Seems dangerous to allow the watcher to take NOTIFY messages that it didn't get the 2xx >response for. What is the watcher going to do if the notifications that it receives don't >mesh, ie.: >- one PA says a contact is online, the other says it's offline? You shouldn't be receiving presence data for the same contact from two different PUA. In fact, each PUA would generate a presence document with tuples with distinct id's. Since the id's are chosen randomly, you'd have to actively be trying to cause an overlap to occur. >- a PA says the subscription is pending, and is an aggregator of the PUA's, but another PA >says the subscription is active, and is not an aggregator? There would be multiple active subscriptions, one for each PA which generated a NOTIFY. >I think you need to have some sort of order of precedence for the watcher to be able to >process the notifications correctly. Before your order of precedence rules were pretty >simple: if the tags match, take it, otherwise don't. Now, you've opened yourself up to all >sorts of new complexities. All of this is covered under sip-events. I don't see any precedence issues. > >Hmmm... There's got to be a better way... The better way is to have aggregating presence agents. But, since we can't guarantee that, I think this kind of treatment may be needed. -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 --- 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 Thu Nov 8 08:43:11 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25845 for ; Thu, 8 Nov 2001 08:43:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA8Deg0r024617; Thu, 8 Nov 2001 08:40:42 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15045; Thu, 8 Nov 2001 08:42:05 -0500 (EST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14914 for ; Thu, 8 Nov 2001 08:05:31 -0500 (EST) Received: from bz0017exch001p.wins.lucent.com (h135-253-94-14.lucent.com [135.253.94.14]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fA8D5BT05516 for ; Thu, 8 Nov 2001 08:05:12 -0500 (EST) Received: by BZ0017EXCH001P with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Nov 2001 11:05:00 -0200 Message-ID: <0F103142B6F6D311A80E0008C71BAC29D455FD@BZ3002EXCH001U> From: "Boaventura, Alberto Magno Silveira (Alberto)" To: mobile-ip@sunroof.eng.sun.com, "'simple@mailman.dynamicsoft.com'" , sip@lists.bell-labs.com, "'isc_sipeg@mail.softswitch.org'" Cc: Jonathan Rosenberg , "Mccann, Peter J (Pete)" , "Hiller, Tom (Tom)" , "'Gonzalo Camarillo'" , "'huilanlu@lucent.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Mobility control for NGN environment 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, 8 Nov 2001 11:04:54 -0200 Greetings All, I am asking your assistance in order to clarify or indicate where I can start my researches about mobility control for NGN environment. I am considering that will be an interface between SIP Proxy and Home Agent for Mobile IP context, but I could not find any proper information. Also, for location based services immerged in NGN and 3GPP2 architecture, who will have the mobile location information? HA/FA? And how to retrieve this location information? Using SIP - Notify Message? Now there are some operations over IS.41, but I understand that will be used for legacy context. Thanks for any return, Alberto. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 8 09:52:41 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27658 for ; Thu, 8 Nov 2001 09:52:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA8EmW0r025136; Thu, 8 Nov 2001 09:48:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15262; Thu, 8 Nov 2001 09:50:06 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15247 for ; Thu, 8 Nov 2001 09:48:56 -0500 (EST) Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fA8ElpY19474 for ; Thu, 8 Nov 2001 09:47:56 -0500 (EST) Received: from flf960bh1.ems.att.com (135.71.27.20) by attrh3i.attrh.att.com (5.5.029) id 3BE2C8EC001225F5; Thu, 8 Nov 2001 09:47:10 -0500 Received: by flf960bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Nov 2001 09:47:10 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F932560F@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: "Boaventura, Alberto Magno Silveira (Alberto)" , mobile-ip@sunroof.eng.sun.com, "'simple@mailman.dynamicsoft.com'" , sip@lists.bell-labs.com, "'isc_sipeg@mail.softswitch.org'" Cc: Jonathan Rosenberg , "Mccann, Peter J (Pete)" , "Hiller, Tom (Tom)" , "'Gonzalo Camarillo'" , "'huilanlu@lucent.com'" Subject: RE: [Simple] Mobility control for NGN environment 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: Thu, 8 Nov 2001 09:45:48 -0500 Hi, Alberto: I do not know whether I would be able to answer all of your questions. Let my try to explain some steps how you perhaps can start your researching. I believe that NGN mobility, the way you are describing, may span from the link layer to the application layer. 1. SIP will deal with mobility in the application/call control layer. This work has just been started. We have to see how SIP UAs and Proxies (different types) play the role related to mobility services when standards are completed. This work is being addressed in SIPPING WG now (not in SIMPLE WG yet). 2. For the network layer, if mobile/cellular IP is used (people may not use this for all cases), the HA and FA will play the role. 3. The point of attachment in the radio link layer may change and, hand-offs will also play a role in defining addresses and media in link layer as users move from place to place. Again, items 1, 2, and 3 will be inter-related directly or indirectly. I guess that the mobility works for items 3 and 2 are well matured and, you can find your answers in those standard areas. For item 1, kindly follow the activities in the SIPPING WG (e.g., 3GPP's requirements). I do believe that we have to address mobility issues for IM and Presence at some point of time, but time is not ripe yet. Hope this helps. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Boaventura, Alberto Magno Silveira (Alberto) [mailto:aboaventura@lucent.com] Sent: Thursday, November 08, 2001 8:05 AM To: mobile-ip@sunroof.eng.sun.com; 'simple@mailman.dynamicsoft.com'; sip@lists.bell-labs.com; 'isc_sipeg@mail.softswitch.org' Cc: Jonathan Rosenberg; Mccann, Peter J (Pete); Hiller, Tom (Tom); 'Gonzalo Camarillo'; 'huilanlu@lucent.com' Subject: [Simple] Mobility control for NGN environment Greetings All, I am asking your assistance in order to clarify or indicate where I can start my researches about mobility control for NGN environment. I am considering that will be an interface between SIP Proxy and Home Agent for Mobile IP context, but I could not find any proper information. Also, for location based services immerged in NGN and 3GPP2 architecture, who will have the mobile location information? HA/FA? And how to retrieve this location information? Using SIP - Notify Message? Now there are some operations over IS.41, but I understand that will be used for legacy context. Thanks for any return, Alberto. _______________________________________________ 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 Thu Nov 8 11:18:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29697 for ; Thu, 8 Nov 2001 11:18:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA8GGT0r025597; Thu, 8 Nov 2001 11:16:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15550; Thu, 8 Nov 2001 11:18:04 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15539 for ; Thu, 8 Nov 2001 11:17:28 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fA8G9wT11162; Thu, 8 Nov 2001 10:09:58 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fA8G9vc11859; Thu, 8 Nov 2001 10:09:57 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA02911; Thu, 8 Nov 2001 10:09:52 -0600 (CST) Reply-To: To: "'Brazier Lachlan'" , "'Jonathan Rosenberg '" , "''Brian Stucker' '" , "''James Undery' '" , "'Robert Sparks '" , "''Moran Tim \(NET/Dallas\)' '" , "''Ngo, Dai \(c\)' '" , "''adam.roach' '" , "''ext Paul Kyzivat' '" Cc: "''simple' '" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C17@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 8 Nov 2001 10:09:55 -0600 Content-Transfer-Encoding: 7bit > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Concerning accepting multiple NOTIFY's. I don't like the idea that the > subscriber must determine the state of the presentity. I > think it's the > responsibility of the presentity, to tell the state it is in. > Otherwise I > really don't believe, that the presentity status can be > handled correctly... For the multiple-NOTIFY case, the subscriber only needs to do what it would normally do for a single NOTIFY. The way that the presence documents are structured, there are multiple tuples presented that must be sorted out and rendered in some fashion. If the body of presence NOTIFY messages contained, for example, a single value of "TRUE" or "FALSE," then your arguments might bear weight. However, as it stands, a single presence document can (and, in my experience using our own presence systems around our department, usually will) contain multiple tuples of presence information, each of which has its own state and a unique ID. When this information arrives from different sources, figuring out what to do with the tuples from multiple NOTIFY messages is precisely the same problem as figuring out what to do with mutiple tuples from the same NOTIFY message. Consider the following document: \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se How would your processing for this document differ from receiving the following three documents from three different sources? \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se If your answer is "not at all," you've defeated your own argument. If your implementation *would* have a problem with the three separate messages, but be able to handle the first, large message just fine, I'd be extremely curious for you to explain why. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 8 11:53:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00529 for ; Thu, 8 Nov 2001 11:53:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA8GnX0r025810; Thu, 8 Nov 2001 11:49:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15671; Thu, 8 Nov 2001 11:51:05 -0500 (EST) 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 LAA15659 for ; Thu, 8 Nov 2001 11:50:13 -0500 (EST) 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 KAA15148 for ; Thu, 8 Nov 2001 10:49:47 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 8 Nov 2001 10:42:27 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Nov 2001 10:48:04 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EBF6C6F@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , "'Brazier Lachlan'" , "'Jonathan Rosenberg '" , "''James Undery' '" , "'Robert Sparks '" , "''Moran Tim (NET/Dallas)' '" , "''Ngo, Dai (c)' '" , "''ext Paul Kyzivat' '" 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_01C16875.24000D10" 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: Thu, 8 Nov 2001 10:48:06 -0600 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_01C16875.24000D10 Content-Type: text/plain; charset="iso-8859-1" If your presentity is split across multiple PA's (which to me is a dangerous game), how do you ensure that the tuple ID is unique for each presence tuple? This is a requirement of the cpim-pidf-01 draft. If the tuple ID is kept unique across the presentity, I can't argue with the fact that it's pretty straightforward to aggregate as you're suggesting below. However, in your example, each PA has a disjoint subset of the presence information. What if one of them was a presence server that had an aggregation of presence information? Then what? Regards, Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Thursday, November 08, 2001 10:10 AM To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian [NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Concerning accepting multiple NOTIFY's. I don't like the idea that the > subscriber must determine the state of the presentity. I > think it's the > responsibility of the presentity, to tell the state it is in. > Otherwise I > really don't believe, that the presentity status can be > handled correctly... For the multiple-NOTIFY case, the subscriber only needs to do what it would normally do for a single NOTIFY. The way that the presence documents are structured, there are multiple tuples presented that must be sorted out and rendered in some fashion. If the body of presence NOTIFY messages contained, for example, a single value of "TRUE" or "FALSE," then your arguments might bear weight. However, as it stands, a single presence document can (and, in my experience using our own presence systems around our department, usually will) contain multiple tuples of presence information, each of which has its own state and a unique ID. When this information arrives from different sources, figuring out what to do with the tuples from multiple NOTIFY messages is precisely the same problem as figuring out what to do with mutiple tuples from the same NOTIFY message. Consider the following document: \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se How would your processing for this document differ from receiving the following three documents from three different sources? \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se If your answer is "not at all," you've defeated your own argument. If your implementation *would* have a problem with the three separate messages, but be able to handle the first, large message just fine, I'd be extremely curious for you to explain why. /a ------_=_NextPart_001_01C16875.24000D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

If your presentity is split across multiple PA's = (which to me is a dangerous game), how do you ensure that the tuple ID = is unique for each presence tuple? This is a requirement of the = cpim-pidf-01 draft.

If the tuple ID is kept unique across the presentity, = I can't argue with the fact that it's pretty straightforward to = aggregate as you're suggesting below. However, in your example, each PA = has a disjoint subset of the presence information. What if one of them = was a presence server that had an aggregation of presence information? = Then what?

Regards,

Brian Stucker


-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Thursday, November 08, 2001 10:10 AM
To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; = Stucker, Brian
[NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks = '; ''Moran Tim
(NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; = ''ext Paul Kyzivat'
'
Cc: ''simple' '
Subject: RE: [Simple] 200 vs. 202


> From: Brazier Lachlan [mailto:lachlan.brazier@siemen= s.at]
>
> Concerning accepting multiple NOTIFY's. I don't = like the idea that the
> subscriber must determine the state of the = presentity. I
> think it's the
> responsibility of the presentity, to tell the = state it is in.
> Otherwise I
> really don't believe, that the presentity = status can be
> handled correctly...

For the multiple-NOTIFY case, the subscriber only = needs to
do what it would normally do for a single NOTIFY. = The way
that the presence documents are structured, there = are multiple
tuples presented that must be sorted out and = rendered in
some fashion.

If the body of presence NOTIFY messages contained, = for
example, a single value of "TRUE" or = "FALSE," then your
arguments might bear weight. However, as it stands, = a single
presence document can (and, in my experience using = our own
presence systems around our department, usually = will) contain
multiple tuples of presence information, each of = which
has its own state and a unique ID.

When this information arrives from different sources, = figuring
out what to do with the tuples from multiple NOTIFY = messages is
precisely the same problem as figuring out what to = do
with mutiple tuples from the same NOTIFY = message.

Consider the following document:

<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple = id=3D"0x12345678">
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:eusadam@bln079.exu.ericsson.se</conta= ct>
  </tuple>
  <tuple = id=3D"0xaaaabbbb">
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"2">sip:37594@138.85.50.74</contact>
  </tuple>
  <tuple = id=3D"0x11111111">
    <status>\n"
      = <value>CLOSED</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:adam@lab17.exu.ericsson.se</contact&g= t;
  </tuple>
</presence>

How would your processing for this document differ = from receiving the
following three documents from three different = sources?

<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple = id=3D"0x12345678">
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:eusadam@bln079.exu.ericsson.se</conta= ct>
  </tuple>
</presence>


<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple = id=3D"0xaaaabbbb">
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"2">sip:37594@138.85.50.74</contact>
  </tuple>
</presence>


<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple = id=3D"0x11111111">
    <status>\n"
      = <value>CLOSED</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:adam@lab17.exu.ericsson.se</contact&g= t;
  </tuple>
</presence>

If your answer is "not at all," you've = defeated your own argument.
If your implementation *would* have a problem with = the three
separate messages, but be able to handle the first, = large message
just fine, I'd be extremely curious for you to = explain why.

/a

------_=_NextPart_001_01C16875.24000D10-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 06:13:01 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06506 for ; Fri, 9 Nov 2001 06:13:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9BAa0r029494; Fri, 9 Nov 2001 06:10:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18970; Fri, 9 Nov 2001 06:12:07 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18959 for ; Fri, 9 Nov 2001 06:11:42 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fA9BBLT10332; Fri, 9 Nov 2001 12:11:21 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id MAA16524; Fri, 9 Nov 2001 12:11:19 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma015523; Fri, 9 Nov 01 12:10:34 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 12:10:33 +0100 Message-ID: From: Brazier Lachlan To: "'Brian Stucker'" , "adam.roach" , Brazier Lachlan , "'Jonathan Rosenberg '" , "''James Undery' '" , "'Robert Sparks '" , "''Moran Tim (NET/Dallas)' '" , "''Ngo, Dai (c)' '" , "''ext Paul Kyzivat' '" Cc: "''simple' '" Subject: AW: [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" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id GAA18959 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, 9 Nov 2001 12:10:24 +0100 Content-Transfer-Encoding: 8bit Hello! Wait a moment. What are we talking about? I always thought we are talking about _USER_ presence, and NOT about the presence status of the clients of the user. If you subscribe to the clients, as the xml scripts below indicate, you tell everybody who can be authenticated, where the user is available. I always thought one intention of SIP was, to hide the exact position of the user behind the user's url, meaning, not needing to know where exactly to send the requests. !!!! Please correct me if I'm wrong !!!! Regarding the two xml scripts below: For the first one, I would need to tell a GUI that there are several "entities" (= clients) for the user, and I have the states of the _clients_. For the second one, I would just change the state of the _user_ in the sequence, as the xml script is processed. I do realise, that I ignore the priority flag. Cu Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] Gesendet am: Donnerstag, 08. November 2001 17:48 An: adam.roach; 'Brazier Lachlan'; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Betreff: RE: [Simple] 200 vs. 202 If your presentity is split across multiple PA's (which to me is a dangerous game), how do you ensure that the tuple ID is unique for each presence tuple? This is a requirement of the cpim-pidf-01 draft. If the tuple ID is kept unique across the presentity, I can't argue with the fact that it's pretty straightforward to aggregate as you're suggesting below. However, in your example, each PA has a disjoint subset of the presence information. What if one of them was a presence server that had an aggregation of presence information? Then what? Regards, Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ] Sent: Thursday, November 08, 2001 10:10 AM To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian [NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 > From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ] > > Concerning accepting multiple NOTIFY's. I don't like the idea that the > subscriber must determine the state of the presentity. I > think it's the > responsibility of the presentity, to tell the state it is in. > Otherwise I > really don't believe, that the presentity status can be > handled correctly... For the multiple-NOTIFY case, the subscriber only needs to do what it would normally do for a single NOTIFY. The way that the presence documents are structured, there are multiple tuples presented that must be sorted out and rendered in some fashion. If the body of presence NOTIFY messages contained, for example, a single value of "TRUE" or "FALSE," then your arguments might bear weight. However, as it stands, a single presence document can (and, in my experience using our own presence systems around our department, usually will) contain multiple tuples of presence information, each of which has its own state and a unique ID. When this information arrives from different sources, figuring out what to do with the tuples from multiple NOTIFY messages is precisely the same problem as figuring out what to do with mutiple tuples from the same NOTIFY message. Consider the following document: \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se How would your processing for this document differ from receiving the following three documents from three different sources? \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se If your answer is "not at all," you've defeated your own argument. If your implementation *would* have a problem with the three separate messages, but be able to handle the first, large message just fine, I'd be extremely curious for you to explain why. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 09:03:37 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10924 for ; Fri, 9 Nov 2001 09:03:36 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9DvT0r000212; Fri, 9 Nov 2001 08:57:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19478; Fri, 9 Nov 2001 08:59:04 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19467 for ; Fri, 9 Nov 2001 08:58:50 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fA9DwVT07531; Fri, 9 Nov 2001 14:58:31 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id OAA23686; Fri, 9 Nov 2001 14:58:30 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma023145; Fri, 9 Nov 01 14:58:07 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 14:58:06 +0100 Message-ID: From: Brazier Lachlan To: "'James Undery'" , Brazier Lachlan , "'Fairlie-Cuninghame, Robert'" , "'Bob Penfield'" , sipping@ietf.org Cc: sean.olson@ericsson.com, "'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] AW: [Sipping] Immediate NOTIFIES change in sip-events-01 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, 9 Nov 2001 14:57:59 +0100 > > > > Sorry for being unclear; I did'nt say to use the ACK like > > with the INVITE. > > Because of the SUBSCRIBE request, only one 2xx response will > > be carried > > upstream. The the ACK will be forked from the proxy to every > > endpoint (= > > presentity). This way every endpoint will know wheter it's > > response was > > received or not (because only the right tag in the To header > > will match). > > I thought this was what we wanted. > > General I don't see why the ACK request should be "untouchable". > > The problem is unreliable transport and specfically > retransmission in this > case. You'd have to alter ACK behaviour to cope with > non-INVITE requests, > this is ugly. Ok, agreed, and I received other reasons why ACK won't work in a neat way. But this also means, that every draft which depends on a 3-way handshake, has to invent it new from the beginning. Lachlan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 11:11:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16806 for ; Fri, 9 Nov 2001 11:11:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9G3W0r001622; Fri, 9 Nov 2001 11:03:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19902; Fri, 9 Nov 2001 11:05:06 -0500 (EST) 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 LAA19887 for ; Fri, 9 Nov 2001 11:04:07 -0500 (EST) 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 KAA22955 for ; Fri, 9 Nov 2001 10:03:48 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 9 Nov 2001 10:00:25 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 10:02:41 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EBF78DC@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Brazier Lachlan , "adam.roach" , Brazier Lachlan , "'Jonathan Rosenberg '" , "''James Undery' '" , "'Robert Sparks '" , "''Moran Tim (NET/Dallas)' '" , "''Ngo, Dai (c)' '" , "''ext Paul Kyzivat' '" 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_01C16937.F8949790" 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, 9 Nov 2001 10:02:45 -0600 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_01C16937.F8949790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the user has a PA in each of their clients, and we fork the = subscribe, you're going to get the presence view from each client. Given, they're *supposed* to know the picture for the entire user if they're a PA, but there's no way of really guaranteeing this unless you have a presence = server (and thus, don't fork). If you take a quick look at the cpim-pidf format of the presence = document, you'll see that you get a tuple for each client device that the user = has, so you'll wind up with a different presence state for each client the user = has. This presents some interesting problems trying to come up with a single = view of what the user's presence status is as a result. Which client device presence tuple represents the user at any given time? What rules do you = use to come to an overall conclusion as to the user's presence state? Given that these are not easily, and consistiently anwserable, you wind = up with a GUI that shows something like: +USER +-client 1 (online) +-client 2 (away) +-client 3 (offline) ... Someone correct me if I'm wrong, but this is what I'm inferring from = the cpim-pidf documetn format. Regards, Brian -----Original Message----- From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] Sent: Friday, November 09, 2001 5:10 AM To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; Brazier Lachlan; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: AW: [Simple] 200 vs. 202 Hello! =20 Wait a moment. What are we talking about? I always thought we are = talking about _USER_ presence, and NOT about the presence status of the clients = of the user. =20 If you subscribe to the clients, as the xml scripts below indicate, you = tell everybody who can be authenticated, where the user is available. I = always thought one intention of SIP was, to hide the exact position of the = user behind the user's url, meaning, not needing to know where exactly to = send the requests. =20 =20 !!!! Please correct me if I'm wrong !!!! =20 =20 Regarding the two xml scripts below: =20 For the first one, I would need to tell a GUI that there are several "entities" (=3D clients) for the user, and I have the states of the = _clients_. =20 For the second one, I would just change the state of the _user_ in the sequence, as the xml script is processed. I do realise, that I ignore = the priority flag. =20 Cu Lachlan -----Urspr=FCngliche Nachricht----- Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] Gesendet am: Donnerstag, 08. November 2001 17:48 An: adam.roach; 'Brazier Lachlan'; 'Jonathan Rosenberg '; ''James = Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext = Paul Kyzivat' ' Cc: ''simple' ' Betreff: RE: [Simple] 200 vs. 202 If your presentity is split across multiple PA's (which to me is a = dangerous game), how do you ensure that the tuple ID is unique for each presence tuple? This is a requirement of the cpim-pidf-01 draft. If the tuple ID is kept unique across the presentity, I can't argue = with the fact that it's pretty straightforward to aggregate as you're suggesting below. However, in your example, each PA has a disjoint subset of the presence information. What if one of them was a presence server that = had an aggregation of presence information? Then what? Regards,=20 Brian Stucker=20 -----Original Message-----=20 From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ]=20 Sent: Thursday, November 08, 2001 10:10 AM=20 To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian=20 [NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim=20 (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul = Kyzivat'=20 '=20 Cc: ''simple' '=20 Subject: RE: [Simple] 200 vs. 202=20 > From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ]=20 >=20 > Concerning accepting multiple NOTIFY's. I don't like the idea that = the=20 > subscriber must determine the state of the presentity. I=20 > think it's the=20 > responsibility of the presentity, to tell the state it is in.=20 > Otherwise I=20 > really don't believe, that the presentity status can be=20 > handled correctly...=20 For the multiple-NOTIFY case, the subscriber only needs to=20 do what it would normally do for a single NOTIFY. The way=20 that the presence documents are structured, there are multiple=20 tuples presented that must be sorted out and rendered in=20 some fashion.=20 If the body of presence NOTIFY messages contained, for=20 example, a single value of "TRUE" or "FALSE," then your=20 arguments might bear weight. However, as it stands, a single=20 presence document can (and, in my experience using our own=20 presence systems around our department, usually will) contain=20 multiple tuples of presence information, each of which=20 has its own state and a unique ID.=20 When this information arrives from different sources, figuring=20 out what to do with the tuples from multiple NOTIFY messages is=20 precisely the same problem as figuring out what to do=20 with mutiple tuples from the same NOTIFY message.=20 Consider the following document:=20 =20 =20 =20 \n"=20 OPEN\n"=20 \n"=20 sip:eusadam@bln079.exu.ericsson.se=20 =20 =20 \n"=20 OPEN\n"=20 \n"=20 sip:37594@138.85.50.74=20 =20 =20 \n"=20 CLOSED\n"=20 \n"=20 sip:adam@lab17.exu.ericsson.se=20 =20 =20 How would your processing for this document differ from receiving the=20 following three documents from three different sources?=20 =20 =20 =20 \n"=20 OPEN\n"=20 \n"=20 sip:eusadam@bln079.exu.ericsson.se=20 =20 =20 =20 =20 =20 \n"=20 OPEN\n"=20 \n"=20 sip:37594@138.85.50.74=20 =20 =20 =20 =20 =20 \n"=20 CLOSED\n"=20 \n"=20 sip:adam@lab17.exu.ericsson.se=20 =20 =20 If your answer is "not at all," you've defeated your own argument.=20 If your implementation *would* have a problem with the three=20 separate messages, but be able to handle the first, large message=20 just fine, I'd be extremely curious for you to explain why.=20 /a=20 ------_=_NextPart_001_01C16937.F8949790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

If the user has a PA in each of their clients, and we = fork the subscribe, you're going to get the presence view from each = client. Given, they're *supposed* to know the picture for the entire = user if they're a PA, but there's no way of really guaranteeing this = unless you have a presence server (and thus, don't fork).

If you take a quick look at the cpim-pidf format of = the presence document, you'll see that you get a tuple for each client = device that the user has, so you'll wind up with a different presence = state for each client the user has. This presents some interesting = problems trying to come up with a single view of what the user's = presence status is as a result. Which client device presence tuple = represents the user at any given time? What rules do you use to come to = an overall conclusion as to the user's presence state?

Given that these are not easily, and consistiently = anwserable, you wind up with a GUI that shows something like:

+USER
  +-client 1 (online)
  +-client 2 (away)
  +-client 3 (offline)
  ...


Someone correct me if I'm wrong, but this is what I'm = inferring from the cpim-pidf documetn format.

Regards,

Brian



-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemen= s.at]
Sent: Friday, November 09, 2001 5:10 AM
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; = Brazier Lachlan;
'Jonathan Rosenberg '; ''James Undery' '; 'Robert = Sparks '; ''Moran Tim
(NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul = Kyzivat' '
Cc: ''simple' '
Subject: AW: [Simple] 200 vs. 202


Hello!
 
Wait a moment. What are we talking about? I always = thought we are talking
about _USER_ presence, and NOT about the presence = status of the clients of
the user.
 
If you subscribe to the clients, as the xml scripts = below indicate, you tell
everybody who can be authenticated, where the user = is available. I always
thought one intention of SIP was, to hide the exact = position of the user
behind the user's url, meaning, not needing to know = where exactly to send
the requests. 
 
!!!! Please correct me if I'm wrong !!!!
 
 
Regarding the two xml scripts below:
 
For the first one, I would need to tell a GUI that = there are several
"entities" (=3D clients) for the user, and = I have the states of the _clients_.
 
For the second one, I would just change the state of = the _user_ in the
sequence, as the xml script is processed. I do = realise, that I ignore the
priority flag.
 
Cu
Lachlan

-----Urspr=FCngliche Nachricht-----
Von: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Gesendet am: Donnerstag, 08. November 2001 = 17:48
An: adam.roach; 'Brazier Lachlan'; 'Jonathan = Rosenberg '; ''James Undery' ';
'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; = ''Ngo, Dai (c)' '; ''ext Paul
Kyzivat' '
Cc: ''simple' '
Betreff: RE: [Simple] 200 vs. 202


If your presentity is split across multiple PA's = (which to me is a dangerous
game), how do you ensure that the tuple ID is unique = for each presence
tuple? This is a requirement of the cpim-pidf-01 = draft.

If the tuple ID is kept unique across the presentity, = I can't argue with the
fact that it's pretty straightforward to aggregate = as you're suggesting
below. However, in your example, each PA has a = disjoint subset of the
presence information. What if one of them was a = presence server that had an
aggregation of presence information? Then = what?

Regards,

Brian Stucker


-----Original Message-----
From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com
<mailto:adam.roach@ericsson.com> ]
Sent: Thursday, November 08, 2001 10:10 AM
To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; = Stucker, Brian
[NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks = '; ''Moran Tim
(NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; = ''ext Paul Kyzivat'
'
Cc: ''simple' '
Subject: RE: [Simple] 200 vs. 202


> From: Brazier Lachlan [ mailto:lachlan.brazier@siemen= s.at
<mailto:lachlan.brazier@siemen= s.at> ]
>
> Concerning accepting multiple NOTIFY's. I don't = like the idea that the
> subscriber must determine the state of the = presentity. I
> think it's the
> responsibility of the presentity, to tell the = state it is in.
> Otherwise I
> really don't believe, that the presentity = status can be
> handled correctly...

For the multiple-NOTIFY case, the subscriber only = needs to
do what it would normally do for a single NOTIFY. = The way
that the presence documents are structured, there = are multiple
tuples presented that must be sorted out and = rendered in
some fashion.

If the body of presence NOTIFY messages contained, = for
example, a single value of "TRUE" or = "FALSE," then your
arguments might bear weight. However, as it stands, = a single
presence document can (and, in my experience using = our own
presence systems around our department, usually = will) contain
multiple tuples of presence information, each of = which
has its own state and a unique ID.

When this information arrives from different sources, = figuring
out what to do with the tuples from multiple NOTIFY = messages is
precisely the same problem as figuring out what to = do
with mutiple tuples from the same NOTIFY message. =

Consider the following document:

<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple id=3D"0x12345678"> =
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:eusadam@bln079.exu.ericsson.se</conta= ct>
  </tuple>
  <tuple id=3D"0xaaaabbbb"> =
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"2">sip:37594@138.85.50.74</contact> =
  </tuple>
  <tuple id=3D"0x11111111"> =
    <status>\n"
      = <value>CLOSED</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:adam@lab17.exu.ericsson.se</contact&g= t;
  </tuple>
</presence>

How would your processing for this document differ = from receiving the
following three documents from three different = sources?

<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple id=3D"0x12345678"> =
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:eusadam@bln079.exu.ericsson.se</conta= ct>
  </tuple>
</presence>


<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple id=3D"0xaaaabbbb"> =
    <status>\n"
      = <value>OPEN</value>\n"
    </status>\n"
    <contact = priority=3D"2">sip:37594@138.85.50.74</contact> =
  </tuple>
</presence>


<presence = xmlns=3D"urn:ietf:params:cpim-presence">
  <presentity = id=3D"sip:adam.roach@ericsson.com"/>
  <tuple id=3D"0x11111111"> =
    <status>\n"
      = <value>CLOSED</value>\n"
    </status>\n"
    <contact = priority=3D"1">sip:adam@lab17.exu.ericsson.se</contact&g= t;
  </tuple>
</presence>

If your answer is "not at all," you've = defeated your own argument.
If your implementation *would* have a problem with = the three
separate messages, but be able to handle the first, = large message
just fine, I'd be extremely curious for you to = explain why.

/a

------_=_NextPart_001_01C16937.F8949790-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 12:44:41 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20529 for ; Fri, 9 Nov 2001 12:44:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9HcV0r002799; Fri, 9 Nov 2001 12:38:31 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20303; Fri, 9 Nov 2001 12:40:06 -0500 (EST) 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 MAA20290 for ; Fri, 9 Nov 2001 12:39:47 -0500 (EST) 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 LAA28082 for ; Fri, 9 Nov 2001 11:39:27 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 9 Nov 2001 11:32:12 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 11:38:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EC471EB@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Brazier Lachlan , "'James Undery'" , "'Fairlie-Cuninghame, Robert'" , "'Bob Penfield'" , sipping@ietf.org Cc: sean.olson@ericsson.com, "'simple@mailman.dynamicsoft.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16945.525DBF60" X-Orig: Subject: [Simple] RE: [Sipping] Immediate NOTIFIES change in sip-events-01 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, 9 Nov 2001 11:38:19 -0600 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_01C16945.525DBF60 Content-Type: text/plain; charset="iso-8859-1" Well that depends. They could copy what SUBSCRIBE/NOTIFY does if that's good enough for their use. Brian -----Original Message----- From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] Sent: Friday, November 09, 2001 7:58 AM To: 'James Undery'; Brazier Lachlan; 'Fairlie-Cuninghame, Robert'; 'Bob Penfield'; sipping@ietf.org Cc: sean.olson@ericsson.com; 'simple@mailman.dynamicsoft.com' Subject: AW: [Sipping] Immediate NOTIFIES change in sip-events-01 > > > > Sorry for being unclear; I did'nt say to use the ACK like > > with the INVITE. > > Because of the SUBSCRIBE request, only one 2xx response will > > be carried > > upstream. The the ACK will be forked from the proxy to every > > endpoint (= > > presentity). This way every endpoint will know wheter it's > > response was > > received or not (because only the right tag in the To header > > will match). > > I thought this was what we wanted. > > General I don't see why the ACK request should be "untouchable". > > The problem is unreliable transport and specfically > retransmission in this > case. You'd have to alter ACK behaviour to cope with > non-INVITE requests, > this is ugly. Ok, agreed, and I received other reasons why ACK won't work in a neat way. But this also means, that every draft which depends on a 3-way handshake, has to invent it new from the beginning. Lachlan _______________________________________________ Sipping mailing list http://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP ------_=_NextPart_001_01C16945.525DBF60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sipping] Immediate NOTIFIES change in sip-events-01

Well that depends. They could copy what = SUBSCRIBE/NOTIFY does if that's good enough for their use.

Brian

-----Original Message-----
From: Brazier Lachlan [mailto:lachlan.brazier@siemen= s.at]
Sent: Friday, November 09, 2001 7:58 AM
To: 'James Undery'; Brazier Lachlan; = 'Fairlie-Cuninghame, Robert'; 'Bob
Penfield'; sipping@ietf.org
Cc: sean.olson@ericsson.com; = 'simple@mailman.dynamicsoft.com'
Subject: AW: [Sipping] Immediate NOTIFIES change in = sip-events-01


> >
> > Sorry for being unclear; I did'nt say to = use the ACK like
> > with the INVITE.
> > Because of the SUBSCRIBE request, only one = 2xx response will
> > be carried
> > upstream. The the ACK will be forked from = the proxy to every
> > endpoint (=3D
> > presentity). This way every endpoint will = know wheter it's
> > response was
> > received or not (because only the right = tag in the To header
> > will match).
> > I thought this was what we wanted.
> > General I don't see why the ACK request = should be "untouchable".
>
> The problem is unreliable transport and = specfically
> retransmission in this
> case. You'd have to alter ACK behaviour to cope = with
> non-INVITE requests,
> this is ugly.

Ok, agreed, and I received other reasons why ACK = won't work in a neat way.
But this also means, that every draft which depends = on a 3-way handshake,
has to invent it new from the beginning.

Lachlan

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application = of SIP
Use sip-implementors@cs.columbia.edu for questions = on current sip
Use sip@ietf.org for new developments of core = SIP

------_=_NextPart_001_01C16945.525DBF60-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 15:33:40 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26874 for ; Fri, 9 Nov 2001 15:33:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9KRT0r004256; Fri, 9 Nov 2001 15:27:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20813; Fri, 9 Nov 2001 15:29:05 -0500 (EST) 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 PAA20802 for ; Fri, 9 Nov 2001 15:28:56 -0500 (EST) 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 fA9KR00r004249; Fri, 9 Nov 2001 15:27:00 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 15:28:19 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , "adam.roach" , "'Brazier Lachlan'" , Jonathan Rosenberg , "''James Undery' '" , Robert Sparks , "''Moran Tim (NET/Dallas)' '" , "''Ngo, Dai (c)' '" , "''ext Paul Kyzivat' '" Cc: "''simple' '" 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: Fri, 9 Nov 2001 15:28:12 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 08, 2001 11:48 AM To: adam.roach; 'Brazier Lachlan'; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 >If your presentity is split across multiple PA's (which to me is a dangerous game), how do >you ensure that the tuple ID is unique for each presence tuple? This is a requirement of >the cpim-pidf-01 draft. You seem to have answered your own question - you ensure the tuple IDs are unique by requiring it in the specification. >If the tuple ID is kept unique across the presentity, I can't argue with the fact that >it's pretty straightforward to aggregate as you're suggesting below. However, in your >example, each PA has a disjoint subset of the presence information. What if one of them >was a presence server that had an aggregation of presence information? Then what? Each tuple is unique; you should not be in the case where you get the same tuple, with the same ID, from different sources (say, one an aggregator, and the other the source of the state itself) but with different data (i.e., different online/offline values). The issue that makes this complicated is that the right view of the presence state of the presentity may NOT be the aggregation of the state of each of its elements. Policy is usuallly injected to filter information, for example, to change the contact ID from a host specific one, if one was used (sip:user@1.2.3.4) to a domain level one (sip:user@foo.com). That policy is ideally placed in the domain of the presentity. That is why I believe that you want to put aggregation there whenever possible. However, the mechanism I have proposed allows things to at least sensibly work if there is no centralized presence server in a domain, where the subscribers perform the aggregation. -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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Thursday, November 08, 2001 10:10 AM To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian [NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > > Concerning accepting multiple NOTIFY's. I don't like the idea that the > subscriber must determine the state of the presentity. I > think it's the > responsibility of the presentity, to tell the state it is in. > Otherwise I > really don't believe, that the presentity status can be > handled correctly... For the multiple-NOTIFY case, the subscriber only needs to do what it would normally do for a single NOTIFY. The way that the presence documents are structured, there are multiple tuples presented that must be sorted out and rendered in some fashion. If the body of presence NOTIFY messages contained, for example, a single value of "TRUE" or "FALSE," then your arguments might bear weight. However, as it stands, a single presence document can (and, in my experience using our own presence systems around our department, usually will) contain multiple tuples of presence information, each of which has its own state and a unique ID. When this information arrives from different sources, figuring out what to do with the tuples from multiple NOTIFY messages is precisely the same problem as figuring out what to do with mutiple tuples from the same NOTIFY message. Consider the following document: \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se How would your processing for this document differ from receiving the following three documents from three different sources? \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se If your answer is "not at all," you've defeated your own argument. If your implementation *would* have a problem with the three separate messages, but be able to handle the first, large message just fine, I'd be extremely curious for you to explain why. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 15:48:42 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27194 for ; Fri, 9 Nov 2001 15:48:42 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9KgS0r004445; Fri, 9 Nov 2001 15:42:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20893; Fri, 9 Nov 2001 15:44:05 -0500 (EST) 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 PAA20882 for ; Fri, 9 Nov 2001 15:43:58 -0500 (EST) 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 fA9KgC0r004435; Fri, 9 Nov 2001 15:42:12 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Nov 2001 15:43:31 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , Brazier Lachlan , "adam.roach" , Brazier Lachlan , Jonathan Rosenberg , "''James Undery' '" , Robert Sparks , "''Moran Tim (NET/Dallas)' '" , "''Ngo, Dai (c)' '" , "''ext Paul Kyzivat' '" Cc: "''simple' '" 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" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id PAA20882 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, 9 Nov 2001 15:43:26 -0500 Content-Transfer-Encoding: 8bit -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, November 09, 2001 11:03 AM To: Brazier Lachlan; adam.roach; Brazier Lachlan; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 >If the user has a PA in each of their clients, and we fork the subscribe, you're going to >get the presence view from each client. Given, they're *supposed* to know the picture for >the entire user if they're a PA, but there's no way of really guaranteeing this unless you >have a presence server (and thus, don't fork). Right. That has been the issue. Each device will only know its own state. >If you take a quick look at the cpim-pidf format of the presence document, you'll see that >you get a tuple for each client device that the user has, so you'll wind up with a >different presence state for each client the user has. This presents some interesting >problems trying to come up with a single view of what the user's presence status is as a >result. Which client device presence tuple represents the user at any given time? What >rules do you use to come to an overall conclusion as to the user's presence state? There is nothing in the model of the presence system that says you are supposed to generate a single online/offline state that represents the presentity. In fact, the model in rfc2778 specifies that the state of a presentity is a collection of tuples, each of which is a communications means, contact address, and status. However, nothing in the model prohibits an aggregator from modeling a presentity with a single (or even no) contact addresses and a single piece of state. -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: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] Sent: Friday, November 09, 2001 5:10 AM To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; Brazier Lachlan; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: AW: [Simple] 200 vs. 202 Hello! Wait a moment. What are we talking about? I always thought we are talking about _USER_ presence, and NOT about the presence status of the clients of the user. If you subscribe to the clients, as the xml scripts below indicate, you tell everybody who can be authenticated, where the user is available. I always thought one intention of SIP was, to hide the exact position of the user behind the user's url, meaning, not needing to know where exactly to send the requests. !!!! Please correct me if I'm wrong !!!! Regarding the two xml scripts below: For the first one, I would need to tell a GUI that there are several "entities" (= clients) for the user, and I have the states of the _clients_. For the second one, I would just change the state of the _user_ in the sequence, as the xml script is processed. I do realise, that I ignore the priority flag. Cu Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] Gesendet am: Donnerstag, 08. November 2001 17:48 An: adam.roach; 'Brazier Lachlan'; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Betreff: RE: [Simple] 200 vs. 202 If your presentity is split across multiple PA's (which to me is a dangerous game), how do you ensure that the tuple ID is unique for each presence tuple? This is a requirement of the cpim-pidf-01 draft. If the tuple ID is kept unique across the presentity, I can't argue with the fact that it's pretty straightforward to aggregate as you're suggesting below. However, in your example, each PA has a disjoint subset of the presence information. What if one of them was a presence server that had an aggregation of presence information? Then what? Regards, Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ] Sent: Thursday, November 08, 2001 10:10 AM To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian [NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 > From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ] > > Concerning accepting multiple NOTIFY's. I don't like the idea that the > subscriber must determine the state of the presentity. I > think it's the > responsibility of the presentity, to tell the state it is in. > Otherwise I > really don't believe, that the presentity status can be > handled correctly... For the multiple-NOTIFY case, the subscriber only needs to do what it would normally do for a single NOTIFY. The way that the presence documents are structured, there are multiple tuples presented that must be sorted out and rendered in some fashion. If the body of presence NOTIFY messages contained, for example, a single value of "TRUE" or "FALSE," then your arguments might bear weight. However, as it stands, a single presence document can (and, in my experience using our own presence systems around our department, usually will) contain multiple tuples of presence information, each of which has its own state and a unique ID. When this information arrives from different sources, figuring out what to do with the tuples from multiple NOTIFY messages is precisely the same problem as figuring out what to do with mutiple tuples from the same NOTIFY message. Consider the following document: \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se How would your processing for this document differ from receiving the following three documents from three different sources? \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se If your answer is "not at all," you've defeated your own argument. If your implementation *would* have a problem with the three separate messages, but be able to handle the first, large message just fine, I'd be extremely curious for you to explain why. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 16:05:32 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27486 for ; Fri, 9 Nov 2001 16:05:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9KxT0r004629; Fri, 9 Nov 2001 15:59:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20974; Fri, 9 Nov 2001 16:01:06 -0500 (EST) Received: from smtpgw6.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20962 for ; Fri, 9 Nov 2001 16:00:32 -0500 (EST) Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id fA9L0Bs06541; Fri, 9 Nov 2001 15:00:11 -0600 (CST) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2654.89) id ; Fri, 9 Nov 2001 15:00:11 -0600 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88066E7CA2@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'mobile-ip@sunroof.eng.sun.com'" , "'simple@mailman.dynamicsoft.com'" , sip@lists.bell-labs.com, "'isc_sipeg@mail.softswitch.org'" Cc: Jonathan Rosenberg , "Mccann, Peter J (Pete)" , "Hiller, Tom (Tom)" , "'Gonzalo Camarillo'" , "'huilanlu@lucent.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: [mobile-ip] Mobility control for NGN environment 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, 9 Nov 2001 15:00:10 -0600 Alberto, The specifics for NGN (All IP) in 3GPP2 are still being developed. Specifically on Location, there are several different types of location information (Access location - which cell site, macro access - which network/domain, and geo-location - x/y/z coordinates) that will need to be managed and "who" has that information may vary. -----Original Message----- From: Boaventura, Alberto Magno Silveira (Alberto) [mailto:aboaventura@lucent.com] Sent: Thursday, November 08, 2001 7:05 AM To: mobile-ip@sunroof.eng.sun.com; 'simple@mailman.dynamicsoft.com'; sip@lists.bell-labs.com; 'isc_sipeg@mail.softswitch.org' Cc: Jonathan Rosenberg; Mccann, Peter J (Pete); Hiller, Tom (Tom); 'Gonzalo Camarillo'; 'huilanlu@lucent.com' Subject: [mobile-ip] Mobility control for NGN environment Greetings All, I am asking your assistance in order to clarify or indicate where I can start my researches about mobility control for NGN environment. I am considering that will be an interface between SIP Proxy and Home Agent for Mobile IP context, but I could not find any proper information. Also, for location based services immerged in NGN and 3GPP2 architecture, who will have the mobile location information? HA/FA? And how to retrieve this location information? Using SIP - Notify Message? Now there are some operations over IS.41, but I understand that will be used for legacy context. Thanks for any return, Alberto. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 9 19:01:20 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00853 for ; Fri, 9 Nov 2001 19:01:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fA9Nwj0r005890; Fri, 9 Nov 2001 18:58:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21556; Fri, 9 Nov 2001 19:00:07 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21543 for ; Fri, 9 Nov 2001 18:59:24 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fA9Nx4T22122; Sat, 10 Nov 2001 00:59:04 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id AAA14041; Sat, 10 Nov 2001 00:59:02 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma013915; Sat, 10 Nov 01 00:58:43 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Sat, 10 Nov 2001 00:58:41 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg '" , "''Brian Stucker' '" , Brazier Lachlan , "'adam.roach '" , Brazier Lachlan , "'''James Undery' ' '" , "'Robert Sparks '" , "'''Moran Tim (NET/Dallas)' ' '" , "'''Ngo, Dai (c)' ' '" , "'''ext Paul Kyzivat' ' '" Cc: "'''simple' ' '" Subject: AW: [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: Sat, 10 Nov 2001 00:58:39 +0100 Hello, thanks, I think I got the point about the tuples. Just two questions: 1) Why should I ever accept a NOTIFY from a client I have never heard off? This will be the case for every client which 2xx response didn't reach me. The difference in the NOTIFY will be in the Tag of the To header and the Contact header. As the draft would say, I SHOULD accept several NOTIFY's, this might not be a big problem. YES/NO???? But it leads to my second question 2) Where do I send my re-Subscribe. To the first address, or to all the Clients I collected through the Contact headers in the NOTIFY's. If I send it to the first address, I ignore the Contact header(s). Is this how it should be? I don't think so. If I send it to the addresses collected through the Contact headers, will my Subscription still be the same as the first one? I'm not sure, but maybe. Thoughts? One thought I got: UserA subscribes for userB. A proxy forks the SUBSCRIBE request to userC and userD. Both send a 2xx response. Both send a NOTIFY with their Contact headers. When userA re-subscribes, does he end up subscribed to userC and userD instead of userB? Probably not when Authentication includes the To header. But then I wont be subscribed to userB anymore as well, which leads me to the case before - I need to ignore the Contact headers to stay subscribed to userB. And what happens if userC will accepts my Subscription? Am I subscribed to userC instead of userB? Any thoughts to this? Cu Lachlan -----Originalnachricht----- Von: Jonathan Rosenberg An: 'Brian Stucker'; Brazier Lachlan; adam.roach; Brazier Lachlan; Jonathan Rosenberg; ''James Undery' '; Robert Sparks; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Gesendet: 09.11.01 21:43 Betreff: RE: [Simple] 200 vs. 202 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Friday, November 09, 2001 11:03 AM To: Brazier Lachlan; adam.roach; Brazier Lachlan; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 >If the user has a PA in each of their clients, and we fork the subscribe, you're going to >get the presence view from each client. Given, they're *supposed* to know the picture for >the entire user if they're a PA, but there's no way of really guaranteeing this unless you >have a presence server (and thus, don't fork). Right. That has been the issue. Each device will only know its own state. >If you take a quick look at the cpim-pidf format of the presence document, you'll see that >you get a tuple for each client device that the user has, so you'll wind up with a >different presence state for each client the user has. This presents some interesting >problems trying to come up with a single view of what the user's presence status is as a >result. Which client device presence tuple represents the user at any given time? What >rules do you use to come to an overall conclusion as to the user's presence state? There is nothing in the model of the presence system that says you are supposed to generate a single online/offline state that represents the presentity. In fact, the model in rfc2778 specifies that the state of a presentity is a collection of tuples, each of which is a communications means, contact address, and status. However, nothing in the model prohibits an aggregator from modeling a presentity with a single (or even no) contact addresses and a single piece of state. -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: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] Sent: Friday, November 09, 2001 5:10 AM To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; Brazier Lachlan; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: AW: [Simple] 200 vs. 202 Hello! Wait a moment. What are we talking about? I always thought we are talking about _USER_ presence, and NOT about the presence status of the clients of the user. If you subscribe to the clients, as the xml scripts below indicate, you tell everybody who can be authenticated, where the user is available. I always thought one intention of SIP was, to hide the exact position of the user behind the user's url, meaning, not needing to know where exactly to send the requests. !!!! Please correct me if I'm wrong !!!! Regarding the two xml scripts below: For the first one, I would need to tell a GUI that there are several "entities" (= clients) for the user, and I have the states of the _clients_. For the second one, I would just change the state of the _user_ in the sequence, as the xml script is processed. I do realise, that I ignore the priority flag. Cu Lachlan -----Ursprüngliche Nachricht----- Von: Brian Stucker [mailto:bstucker@nortelnetworks.com] Gesendet am: Donnerstag, 08. November 2001 17:48 An: adam.roach; 'Brazier Lachlan'; 'Jonathan Rosenberg '; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Betreff: RE: [Simple] 200 vs. 202 If your presentity is split across multiple PA's (which to me is a dangerous game), how do you ensure that the tuple ID is unique for each presence tuple? This is a requirement of the cpim-pidf-01 draft. If the tuple ID is kept unique across the presentity, I can't argue with the fact that it's pretty straightforward to aggregate as you're suggesting below. However, in your example, each PA has a disjoint subset of the presence information. What if one of them was a presence server that had an aggregation of presence information? Then what? Regards, Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [ mailto:adam.roach@ericsson.com ] Sent: Thursday, November 08, 2001 10:10 AM To: 'Brazier Lachlan'; 'Jonathan Rosenberg '; Stucker, Brian [NGB:B635:EXCH]; ''James Undery' '; 'Robert Sparks '; ''Moran Tim (NET/Dallas)' '; ''Ngo, Dai (c)' '; ''adam.roach' '; ''ext Paul Kyzivat' ' Cc: ''simple' ' Subject: RE: [Simple] 200 vs. 202 > From: Brazier Lachlan [ mailto:lachlan.brazier@siemens.at ] > > Concerning accepting multiple NOTIFY's. I don't like the idea that the > subscriber must determine the state of the presentity. I > think it's the > responsibility of the presentity, to tell the state it is in. > Otherwise I > really don't believe, that the presentity status can be > handled correctly... For the multiple-NOTIFY case, the subscriber only needs to do what it would normally do for a single NOTIFY. The way that the presence documents are structured, there are multiple tuples presented that must be sorted out and rendered in some fashion. If the body of presence NOTIFY messages contained, for example, a single value of "TRUE" or "FALSE," then your arguments might bear weight. However, as it stands, a single presence document can (and, in my experience using our own presence systems around our department, usually will) contain multiple tuples of presence information, each of which has its own state and a unique ID. When this information arrives from different sources, figuring out what to do with the tuples from multiple NOTIFY messages is precisely the same problem as figuring out what to do with mutiple tuples from the same NOTIFY message. Consider the following document: \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se How would your processing for this document differ from receiving the following three documents from three different sources? \n" OPEN\n" \n" sip:eusadam@bln079.exu.ericsson.se \n" OPEN\n" \n" sip:37594@138.85.50.74 \n" CLOSED\n" \n" sip:adam@lab17.exu.ericsson.se If your answer is "not at all," you've defeated your own argument. If your implementation *would* have a problem with the three separate messages, but be able to handle the first, large message just fine, I'd be extremely curious for you to explain why. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 11:20:39 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09570 for ; Mon, 12 Nov 2001 11:20:39 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACFtnCJ002406; Mon, 12 Nov 2001 10:55:49 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01422; Mon, 12 Nov 2001 10:57:16 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01410 for ; Mon, 12 Nov 2001 10:56:33 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fACFuoA27029 for ; Mon, 12 Nov 2001 17:56:50 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 12 Nov 2001 17:56:06 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 12 Nov 2001 17:56:03 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC5C@esebe013.NOE.Nokia.com> To: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Expires in MESSAGE 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, 12 Nov 2001 17:54:32 +0200 Hi All, draft-ietf-simple-im-01 doesn't currently say anything about the usage of Expires in MESSAGE. However, it is marked as optional. Do we consider the meaning of Expires in a MESSAGE to follow the default meaning as in bis-05: The Expires header field gives the date and time after which the message (or content) expires. The precise meaning of this is method dependent. ...or might we consider adding something special, e.g., Expires: 0 to indicate, that the IM is only valid right now, and cannot be forwarded to email, SMS, whatever? Regards, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 12:44:14 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12756 for ; Mon, 12 Nov 2001 12:44:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACHfwCJ003833; Mon, 12 Nov 2001 12:41:58 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01774; Mon, 12 Nov 2001 12:42:13 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01763 for ; Mon, 12 Nov 2001 12:41:05 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fACHeiP08715 for ; Mon, 12 Nov 2001 11:40:44 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fACHehK20971 for ; Mon, 12 Nov 2001 11:40:43 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Nov 12 11:40:33 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 11:40:33 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'aki.niemi@nokia.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16BA1.213F5570" 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, 12 Nov 2001 11:40:33 -0600 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_01C16BA1.213F5570 Content-Type: text/plain; charset="iso-8859-1" >Hi All, > >draft-ietf-simple-im-01 doesn't currently say anything about >the usage of >Expires in MESSAGE. However, it is marked as optional. > >Do we consider the meaning of Expires in a MESSAGE to follow >the default >meaning as in bis-05: > > The Expires header field gives the date and time after which the > message (or content) expires. The precise meaning of this is method > dependent. This seems like the most logical interpretation for MESSAGE. This would also seem to encompass the application you have in mind below. > >...or might we consider adding something special, e.g., Expires: 0 to >indicate, that the IM is only valid right now, and cannot be >forwarded to >email, SMS, whatever? > >Regards, >Aki Regards, Sean ------_=_NextPart_001_01C16BA1.213F5570 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Expires in MESSAGE

>Hi All,
>
>draft-ietf-simple-im-01 doesn't currently say anything about
>the usage of
>Expires in MESSAGE. However, it is marked as optional.
>
>Do we consider the meaning of Expires in a MESSAGE to follow
>the default
>meaning as in bis-05:
>      
>   The Expires header field gives the date and time after which the
>   message (or content) expires. The precise meaning of this is method
>   dependent.

This seems like the most logical interpretation for MESSAGE.
This would also seem to encompass the application you have in
mind below.

>
>...or might we consider adding something special, e.g., Expires: 0 to
>indicate,  that the IM is only valid right now, and cannot be
>forwarded to
>email, SMS, whatever? 
>
>Regards,
>Aki

Regards,
Sean

------_=_NextPart_001_01C16BA1.213F5570-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 12:58:41 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13278 for ; Mon, 12 Nov 2001 12:58:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACHqPCJ003961; Mon, 12 Nov 2001 12:52:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01830; Mon, 12 Nov 2001 12:54:05 -0500 (EST) 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 MAA01819 for ; Mon, 12 Nov 2001 12:53:24 -0500 (EST) 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 fACHphCJ003943 for ; Mon, 12 Nov 2001 12:51:43 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 12:53:04 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E790@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks 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] Reacting to multiple sources of presence data (was 200v202) 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, 12 Nov 2001 12:53:02 -0500 I'm not sure everyone who has contributed to this conversation is working on the same problem. (I'm not even sure I understand the problem yet myself). So, here's an attempt to summarize the issue we're looking at. Given that: * A SUBSCRIBE may fork * Multiple endpoints may accept the SUBSCRIBE * These notifying endpoints may not have identical presence documents to provide The root problem is: * How do we reconcile the different documents? There have been a handful of proposed solutions, each bringing their own set of additional problems. I think these two capture the main flavors of the proposals: 1) Accept only the notifier who's 2xx was chosen by the proxy mesh to be forwarded to the subscriber. Ignore input from all other notifiers. Rely on configuration of all the elements to provide the "right" presence document. (I think this is the currently documented solution) Problems: * Doesn't allow state aggregation (but maybe that should be a domain-specific application and not something we try to do generically in protocol) 2) Accept all notifiers by springing subscriptions into being on receiving NOTIFYs with matching dialog identifiers (but unknown to-tags). Each such subscription exists independently of the others, with its own lifetime and route-set. Rely on configuration of all the elements to provide the "right" set of notifiers. Problems: * How do you resolve conflicts during state composition? * Is the DoS opportunity this creates acceptable? * The configuration necessary to reach the "right" set is very restrictive. (For instance, all the notifiers must be behind the same number of challenging proxies). What have I missed? RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 14:01:53 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15361 for ; Mon, 12 Nov 2001 14:01:53 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACItQCJ004398; Mon, 12 Nov 2001 13:55:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02036; Mon, 12 Nov 2001 13:57:05 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02025 for ; Mon, 12 Nov 2001 13:56:58 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fACIvIA06320 for ; Mon, 12 Nov 2001 20:57:18 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 12 Nov 2001 20:56:36 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 12 Nov 2001 20:56:36 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC5E@esebe013.NOE.Nokia.com> To: sean.olson@ericsson.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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, 12 Nov 2001 20:56:32 +0200 Hi Sean, > This seems like the most logical interpretation for MESSAGE. > This would also seem to encompass the application you have in > mind below. I assumed the zero expiry is only defined for REGISTER and SUBSCRIBE, and maybe similar definitions for its semantics for MESSAGE would be needed? Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 14:30:31 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16012 for ; Mon, 12 Nov 2001 14:30:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACJOPCJ004850; Mon, 12 Nov 2001 14:24:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02144; Mon, 12 Nov 2001 14:26:05 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02133 for ; Mon, 12 Nov 2001 14:25:15 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fACJOsT00401 for ; Mon, 12 Nov 2001 13:24:55 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fACJOsn10306 for ; Mon, 12 Nov 2001 13:24:54 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Nov 12 13:24:54 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 13:24:54 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'aki.niemi@nokia.com'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16BAF.B4ED3D60" 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, 12 Nov 2001 13:24:54 -0600 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_01C16BAF.B4ED3D60 Content-Type: text/plain; charset="iso-8859-1" Hi, I see what you are saying. Should the "Expires: 0" be interpreted as in a REGISTER or as in an INVITE? I was thinking it would be treated the same as in an INVITE. If you receive a MESSAGE with an Expires: that has passed (or is literally zero), you return a 400 response and "drop" the MESSAGE. /sean >Hi Sean, > >> This seems like the most logical interpretation for MESSAGE. >> This would also seem to encompass the application you have in >> mind below. > >I assumed the zero expiry is only defined for REGISTER and >SUBSCRIBE, and >maybe similar definitions for its semantics for MESSAGE would >be needed? > >Cheers, >Aki > ------_=_NextPart_001_01C16BAF.B4ED3D60 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Expires in MESSAGE

Hi,

I see what you are saying. Should the "Expires: 0" be
interpreted as in a REGISTER or as in an INVITE? I was
thinking it would be treated the same as in an INVITE.
If you receive a MESSAGE with an Expires: that has passed
(or is literally zero), you return a 400 response and
"drop" the MESSAGE.

/sean

>Hi Sean,
>
>> This seems like the most logical interpretation for MESSAGE.
>> This would also seem to encompass the application you have in
>> mind below.
>
>I assumed the zero expiry is only defined for REGISTER and
>SUBSCRIBE, and
>maybe similar definitions for its semantics for MESSAGE would
>be needed?
>
>Cheers,
>Aki
>

------_=_NextPart_001_01C16BAF.B4ED3D60-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 15:59:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18375 for ; Mon, 12 Nov 2001 15:59:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACKuVCJ005887; Mon, 12 Nov 2001 15:56:31 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02428; Mon, 12 Nov 2001 15:58:06 -0500 (EST) 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 PAA02417 for ; Mon, 12 Nov 2001 15:57:32 -0500 (EST) 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 fACKtrCJ005878; Mon, 12 Nov 2001 15:55:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 15:57:12 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E797@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Sean Olson , "'aki.niemi@nokia.com'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16BBC.971B58A0" 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, 12 Nov 2001 15:57:07 -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_01C16BBC.971B58A0 Content-Type: text/plain; charset="iso-8859-1" Interpreting Expires to put bounds on the validity of the content of the message is the correct thing to do. This is, however, information for the applications (or people) using the message, not for the routing fabric. In particular, I don't think it will make sense to reject "expired" messages at, say, a proxy. Even at an endpoint, it should be up the the application running above SIP to decide if it wants to process the "expired" message. Taking that decision away (by requiring the SIP implementation itself to reject the expired message) will do harm. RjS -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Monday, November 12, 2001 1:25 PM To: 'aki.niemi@nokia.com' Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE Hi, I see what you are saying. Should the "Expires: 0" be interpreted as in a REGISTER or as in an INVITE? I was thinking it would be treated the same as in an INVITE. If you receive a MESSAGE with an Expires: that has passed (or is literally zero), you return a 400 response and "drop" the MESSAGE. /sean >Hi Sean, > >> This seems like the most logical interpretation for MESSAGE. >> This would also seem to encompass the application you have in >> mind below. > >I assumed the zero expiry is only defined for REGISTER and >SUBSCRIBE, and >maybe similar definitions for its semantics for MESSAGE would >be needed? > >Cheers, >Aki > ------_=_NextPart_001_01C16BBC.971B58A0 Content-Type: text/html; charset="iso-8859-1" RE: [Simple] Expires in MESSAGE
Interpreting Expires to put bounds on the validity of the content
of the message is the correct thing to do.
 
This is, however, information for the applications (or people) using
the message, not for the routing fabric. In particular, I don't think
it will make sense to reject "expired" messages at, say, a proxy.
Even at an endpoint, it should be up the the application running
above SIP to decide if it wants to process the "expired" message.
Taking that decision away (by requiring the SIP implementation
itself to reject the expired message) will do harm.
 
RjS
 
-----Original Message-----
From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com]
Sent: Monday, November 12, 2001 1:25 PM
To: 'aki.niemi@nokia.com'
Cc: simple@mailman.dynamicsoft.com
Subject: RE: [Simple] Expires in MESSAGE

Hi,

I see what you are saying. Should the "Expires: 0" be
interpreted as in a REGISTER or as in an INVITE? I was
thinking it would be treated the same as in an INVITE.
If you receive a MESSAGE with an Expires: that has passed
(or is literally zero), you return a 400 response and
"drop" the MESSAGE.

/sean

>Hi Sean,
>
>> This seems like the most logical interpretation for MESSAGE.
>> This would also seem to encompass the application you have in
>> mind below.
>
>I assumed the zero expiry is only defined for REGISTER and
>SUBSCRIBE, and
>maybe similar definitions for its semantics for MESSAGE would
>be needed?
>
>Cheers,
>Aki
>

------_=_NextPart_001_01C16BBC.971B58A0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 16:13:40 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18853 for ; Mon, 12 Nov 2001 16:13:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACL7TCJ006015; Mon, 12 Nov 2001 16:07:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02482; Mon, 12 Nov 2001 16:09:07 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02471 for ; Mon, 12 Nov 2001 16:08:51 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fACL82Y23484; Mon, 12 Nov 2001 16:08:05 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id QAA09499; Mon, 12 Nov 2001 16:08:28 -0500 (EST) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 16:07:58 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F93B4AB8@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: Robert Sparks , Sean Olson , "'aki.niemi@nokia.com'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE 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, 12 Nov 2001 16:07:52 -0500 Hi, Roberts: Is not that "MESSAGE" another method in SIP like INVITEs, etc.? If so, why do we not use the same rules (e.g., the interpretations can be made in the SIP layer)? Radhika -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] Sent: Monday, November 12, 2001 3:57 PM To: Sean Olson; 'aki.niemi@nokia.com' Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE Interpreting Expires to put bounds on the validity of the content of the message is the correct thing to do. This is, however, information for the applications (or people) using the message, not for the routing fabric. In particular, I don't think it will make sense to reject "expired" messages at, say, a proxy. Even at an endpoint, it should be up the the application running above SIP to decide if it wants to process the "expired" message. Taking that decision away (by requiring the SIP implementation itself to reject the expired message) will do harm. RjS -----Original Message----- From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] Sent: Monday, November 12, 2001 1:25 PM To: 'aki.niemi@nokia.com' Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE Hi, I see what you are saying. Should the "Expires: 0" be interpreted as in a REGISTER or as in an INVITE? I was thinking it would be treated the same as in an INVITE. If you receive a MESSAGE with an Expires: that has passed (or is literally zero), you return a 400 response and "drop" the MESSAGE. /sean >Hi Sean, > >> This seems like the most logical interpretation for MESSAGE. >> This would also seem to encompass the application you have in >> mind below. > >I assumed the zero expiry is only defined for REGISTER and >SUBSCRIBE, and >maybe similar definitions for its semantics for MESSAGE would >be needed? > >Cheers, >Aki > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 16:55:32 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20067 for ; Mon, 12 Nov 2001 16:55:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACLnSCJ006477; Mon, 12 Nov 2001 16:49:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02624; Mon, 12 Nov 2001 16:51:05 -0500 (EST) 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 QAA02612 for ; Mon, 12 Nov 2001 16:50:05 -0500 (EST) 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 fACLmOCJ006466; Mon, 12 Nov 2001 16:48:24 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 16:49:44 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E799@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Roy, Radhika R, ALCTA'" , Robert Sparks , Sean Olson , "'aki.niemi@nokia.com'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE 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, 12 Nov 2001 16:49:41 -0500 I'm not sure I understand your point. Yes, MESSAGE is a SIP method. There are no "same rules" to be considered. The core spec provides meaning to Expires for REGISTER, and (somewhat loosely) for INVITE, and those are different! It has no meaning for the other core methods (Expires is meaningless for BYE). New methods must specify meaning (if any) on their own. For MESSAGE, I hold that the Expire header contains the period for which the content of the message should be considered valid, and it should be up to the applications involved to decide what to do with expired messages, not the transport mechanism. Different applications are likely to need to make different choices. I may have a service where it is useful for me to know you invited me to lunch, even though I didn't see your invitation until it was too late to accept. RjS > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, November 12, 2001 3:08 PM > To: Robert Sparks; Sean Olson; 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > Hi, Roberts: > > Is not that "MESSAGE" another method in SIP like INVITEs, > etc.? If so, why > do we not use the same rules (e.g., the interpretations can > be made in the > SIP layer)? > > Radhika > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, November 12, 2001 3:57 PM > To: Sean Olson; 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > Interpreting Expires to put bounds on the validity of the content > of the message is the correct thing to do. > > This is, however, information for the applications (or people) using > the message, not for the routing fabric. In particular, I don't think > it will make sense to reject "expired" messages at, say, a proxy. > Even at an endpoint, it should be up the the application running > above SIP to decide if it wants to process the "expired" message. > Taking that decision away (by requiring the SIP implementation > itself to reject the expired message) will do harm. > > RjS > > -----Original Message----- > From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > Sent: Monday, November 12, 2001 1:25 PM > To: 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > > Hi, > > I see what you are saying. Should the "Expires: 0" be > interpreted as in a REGISTER or as in an INVITE? I was > thinking it would be treated the same as in an INVITE. > If you receive a MESSAGE with an Expires: that has passed > (or is literally zero), you return a 400 response and > "drop" the MESSAGE. > > /sean > > >Hi Sean, > > > >> This seems like the most logical interpretation for MESSAGE. > >> This would also seem to encompass the application you have in > >> mind below. > > > >I assumed the zero expiry is only defined for REGISTER and > >SUBSCRIBE, and > >maybe similar definitions for its semantics for MESSAGE would > >be needed? > > > >Cheers, > >Aki > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 12 16:57:13 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20120 for ; Mon, 12 Nov 2001 16:57:13 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACLsRCJ006629; Mon, 12 Nov 2001 16:54:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02659; Mon, 12 Nov 2001 16:56:05 -0500 (EST) 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 QAA02648 for ; Mon, 12 Nov 2001 16:55:20 -0500 (EST) 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 fACLrdCJ006616; Mon, 12 Nov 2001 16:53:39 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 16:54:59 -0500 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'Roy, Radhika R, ALCTA'" , Sean Olson , "'aki.niemi@nokia.com'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE 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, 12 Nov 2001 16:54:57 -0500 I agree with Robert here. Proxies should ignore Expires in MESSAGE. If a UA wants to use it in some way, for example to limit the display of an IM on the screen, that is reasonable. -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: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, November 12, 2001 4:50 PM > To: 'Roy, Radhika R, ALCTA'; Robert Sparks; Sean Olson; > 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > I'm not sure I understand your point. > > Yes, MESSAGE is a SIP method. > > There are no "same rules" to be considered. The core > spec provides meaning to Expires for REGISTER, and > (somewhat loosely) for INVITE, and those are different! > It has no meaning for the other core methods (Expires > is meaningless for BYE). New methods must specify meaning > (if any) on their own. > > For MESSAGE, I hold that the Expire header contains the > period for which the content of the message should be > considered valid, and it should be up to the applications > involved to decide what to do with expired messages, not > the transport mechanism. Different applications are likely > to need to make different choices. I may have a service where > it is useful for me to know you invited me to lunch, even > though I didn't see your invitation until it was too late to > accept. > > > RjS > > > > -----Original Message----- > > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > > Sent: Monday, November 12, 2001 3:08 PM > > To: Robert Sparks; Sean Olson; 'aki.niemi@nokia.com' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Expires in MESSAGE > > > > > > Hi, Roberts: > > > > Is not that "MESSAGE" another method in SIP like INVITEs, > > etc.? If so, why > > do we not use the same rules (e.g., the interpretations can > > be made in the > > SIP layer)? > > > > Radhika > > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Sent: Monday, November 12, 2001 3:57 PM > > To: Sean Olson; 'aki.niemi@nokia.com' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Expires in MESSAGE > > > > > > Interpreting Expires to put bounds on the validity of the content > > of the message is the correct thing to do. > > > > This is, however, information for the applications (or people) using > > the message, not for the routing fabric. In particular, I > don't think > > it will make sense to reject "expired" messages at, say, a proxy. > > Even at an endpoint, it should be up the the application running > > above SIP to decide if it wants to process the "expired" message. > > Taking that decision away (by requiring the SIP implementation > > itself to reject the expired message) will do harm. > > > > RjS > > > > -----Original Message----- > > From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > > Sent: Monday, November 12, 2001 1:25 PM > > To: 'aki.niemi@nokia.com' > > Cc: simple@mailman.dynamicsoft.com > > Subject: RE: [Simple] Expires in MESSAGE > > > > > > > > Hi, > > > > I see what you are saying. Should the "Expires: 0" be > > interpreted as in a REGISTER or as in an INVITE? I was > > thinking it would be treated the same as in an INVITE. > > If you receive a MESSAGE with an Expires: that has passed > > (or is literally zero), you return a 400 response and > > "drop" the MESSAGE. > > > > /sean > > > > >Hi Sean, > > > > > >> This seems like the most logical interpretation for MESSAGE. > > >> This would also seem to encompass the application you have in > > >> mind below. > > > > > >I assumed the zero expiry is only defined for REGISTER and > > >SUBSCRIBE, and > > >maybe similar definitions for its semantics for MESSAGE would > > >be needed? > > > > > >Cheers, > > >Aki > > > > > > _______________________________________________ > 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 Mon Nov 12 17:07:46 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20396 for ; Mon, 12 Nov 2001 17:07:45 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACM1VCJ006763; Mon, 12 Nov 2001 17:01:31 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02724; Mon, 12 Nov 2001 17:03:08 -0500 (EST) 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 RAA02713 for ; Mon, 12 Nov 2001 17:02:19 -0500 (EST) 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 fACM0eCJ006744 for ; Mon, 12 Nov 2001 17:00:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 17:01:59 -0500 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) 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, 12 Nov 2001 17:01:59 -0500 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, November 12, 2001 12:53 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Reacting to multiple sources of presence data (was > 200v202) > > Given that: > > * A SUBSCRIBE may fork > * Multiple endpoints may accept the SUBSCRIBE > * These notifying endpoints may not have identical > presence documents to provide > > The root problem is: > * How do we reconcile the different documents? Yes, that is the essence of the problem. > > There have been a handful of proposed solutions, each > bringing their own set of additional problems. I think > these two capture the main flavors of the proposals: > > 1) Accept only the notifier who's 2xx was chosen by > the proxy mesh to be forwarded to the subscriber. > Ignore input from all other notifiers. > Rely on configuration of all the elements to provide > the "right" presence document. > (I think this is the currently documented solution) > Problems: > * Doesn't allow state aggregation (but maybe that > should be a domain-specific application and not > something we try to do generically in protocol) Another problem I pointed out is that the 2xx which was "chosen by the proxy mesh" may be a 202, and later be rejected, whereas one of the 2xx which was not chosen, is later accepted. However, its NOTIFY is discarded. > > 2) Accept all notifiers by springing subscriptions into > being on receiving NOTIFYs with matching dialog identifiers > (but unknown to-tags). Each such subscription exists > independently of the others, with its own lifetime and > route-set. Rely on configuration of all the elements > to provide the "right" set of notifiers. > Problems: > * How do you resolve conflicts during state composition? > * Is the DoS opportunity this creates acceptable? I'm not sure I understand the DoS opportunity. Can you elaborate? > * The configuration necessary to reach the "right" set > is very restrictive. (For instance, all the notifiers > must be behind the same number of challenging proxies). I don't see that at all. What has the number of proxies got to do with it? -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 Mon Nov 12 17:22:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21066 for ; Mon, 12 Nov 2001 17:22:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fACMKTCJ007012; Mon, 12 Nov 2001 17:20:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02829; Mon, 12 Nov 2001 17:22:06 -0500 (EST) 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 RAA02813 for ; Mon, 12 Nov 2001 17:21:20 -0500 (EST) 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 fACMJfCJ006999 for ; Mon, 12 Nov 2001 17:19:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 12 Nov 2001 17:21:01 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E79A@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) 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, 12 Nov 2001 17:18:52 -0500 inline > > There have been a handful of proposed solutions, each > > bringing their own set of additional problems. I think > > these two capture the main flavors of the proposals: > > > > 1) Accept only the notifier who's 2xx was chosen by > > the proxy mesh to be forwarded to the subscriber. > > Ignore input from all other notifiers. > > Rely on configuration of all the elements to provide > > the "right" presence document. > > (I think this is the currently documented solution) > > Problems: > > * Doesn't allow state aggregation (but maybe that > > should be a domain-specific application and not > > something we try to do generically in protocol) > > Another problem I pointed out is that the 2xx which was > "chosen by the proxy mesh" may be a 202, and later be > rejected, whereas one of the 2xx which was not chosen, is > later accepted. However, its NOTIFY is discarded. I don't understand this scenario yet. What does it mean to be later rejected or accepted? > > > > > 2) Accept all notifiers by springing subscriptions into > > being on receiving NOTIFYs with matching dialog identifiers > > (but unknown to-tags). Each such subscription exists > > independently of the others, with its own lifetime and > > route-set. Rely on configuration of all the elements > > to provide the "right" set of notifiers. > > Problems: > > * How do you resolve conflicts during state composition? > > * Is the DoS opportunity this creates acceptable? > > I'm not sure I understand the DoS opportunity. Can you elaborate? Assume you subscribe to me, and for some reason I decide to take your client down. All I need to do is send some number of NOTIFYs with different To: tags (preferably with very large route-sets that you now have to maintain), continuing until you run out of memory and die. This will require far less effort on my part than simply trying to flood your network connection. > > > * The configuration necessary to reach the "right" set > > is very restrictive. (For instance, all the notifiers > > must be behind the same number of challenging proxies). > > I don't see that at all. What has the number of proxies got > to do with it? Consider the following topology notifier 1 / subscriber --- P1 \ P2 - notifier 2 Where P2 issues a 407. If notifier 1 issues a 2xx, you will never be able to get presence information from notifier 2 - you will never see its challenge. If you needed the information from both notifer 1 and notifier 2 in order to be correct, the same number of challenging proxies would have to exist on the path from subscriber to notifier 1 and the path from subscriber to notifier 2, or one of them will be left out in the cold. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 03:12:01 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17817 for ; Tue, 13 Nov 2001 03:12:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAD85SCJ009098; Tue, 13 Nov 2001 03:05:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04546; Tue, 13 Nov 2001 03:07:05 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04535 for ; Tue, 13 Nov 2001 03:06:26 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fAD862T00499; Tue, 13 Nov 2001 09:06:02 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id JAA13474; Tue, 13 Nov 2001 09:06:00 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma010372; Tue, 13 Nov 01 09:04:02 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 09:04:00 +0100 Message-ID: From: Brazier Lachlan To: "'Robert Sparks '" , "'Jonathan Rosenberg '" , "''simple@mailman.dynamicsoft.com' '" Cc: "'simple@mailman.dynamicsoft.com'" Subject: AW: [Simple] Reacting to multiple sources of presence data (was 2 00v202) 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, 13 Nov 2001 09:03:56 +0100 Hmm, would it help to ignore the To-tag and include a new Header, lets say something like "NOTIFY-ID", and mandate, that the NOTIFY-ID MUST be the same for all clients who want to act as PA for a url. I think this could work, because any client acting as PA actually needs the information that it can act as a PA for a given url. This would also allow a user to genereate it's own "code" to avoid being used as DoS launcher. Moreover, when the presentity goes on holiday, it can tell it's collegue, partner etc. the code. As the "code" is user defined, the "code" can be changed whenever necessary. Even better, as it is a new Header, you can encrypt your "code". Is this any good?? Cu Lachlan -----Originalnachricht----- Von: Robert Sparks An: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' Gesendet: 12.11.01 23:18 Betreff: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) inline > > There have been a handful of proposed solutions, each > > bringing their own set of additional problems. I think > > these two capture the main flavors of the proposals: > > > > 1) Accept only the notifier who's 2xx was chosen by > > the proxy mesh to be forwarded to the subscriber. > > Ignore input from all other notifiers. > > Rely on configuration of all the elements to provide > > the "right" presence document. > > (I think this is the currently documented solution) > > Problems: > > * Doesn't allow state aggregation (but maybe that > > should be a domain-specific application and not > > something we try to do generically in protocol) > > Another problem I pointed out is that the 2xx which was > "chosen by the proxy mesh" may be a 202, and later be > rejected, whereas one of the 2xx which was not chosen, is > later accepted. However, its NOTIFY is discarded. I don't understand this scenario yet. What does it mean to be later rejected or accepted? > > > > > 2) Accept all notifiers by springing subscriptions into > > being on receiving NOTIFYs with matching dialog identifiers > > (but unknown to-tags). Each such subscription exists > > independently of the others, with its own lifetime and > > route-set. Rely on configuration of all the elements > > to provide the "right" set of notifiers. > > Problems: > > * How do you resolve conflicts during state composition? > > * Is the DoS opportunity this creates acceptable? > > I'm not sure I understand the DoS opportunity. Can you elaborate? Assume you subscribe to me, and for some reason I decide to take your client down. All I need to do is send some number of NOTIFYs with different To: tags (preferably with very large route-sets that you now have to maintain), continuing until you run out of memory and die. This will require far less effort on my part than simply trying to flood your network connection. > > > * The configuration necessary to reach the "right" set > > is very restrictive. (For instance, all the notifiers > > must be behind the same number of challenging proxies). > > I don't see that at all. What has the number of proxies got > to do with it? Consider the following topology notifier 1 / subscriber --- P1 \ P2 - notifier 2 Where P2 issues a 407. If notifier 1 issues a 2xx, you will never be able to get presence information from notifier 2 - you will never see its challenge. If you needed the information from both notifer 1 and notifier 2 in order to be correct, the same number of challenging proxies would have to exist on the path from subscriber to notifier 1 and the path from subscriber to notifier 2, or one of them will be left out in the cold. RjS _______________________________________________ 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 Tue Nov 13 03:47:37 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18078 for ; Tue, 13 Nov 2001 03:47:37 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAD8fTCJ009214; Tue, 13 Nov 2001 03:41:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04676; Tue, 13 Nov 2001 03:43:05 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04665 for ; Tue, 13 Nov 2001 03:42:12 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fAD8frT11114; Tue, 13 Nov 2001 09:41:53 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id JAA09439; Tue, 13 Nov 2001 09:41:52 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma007620; Tue, 13 Nov 01 09:40:23 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 09:40:17 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg '" , "''simple@mailman.dynamicsoft.com' '" Cc: "'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] Contact header in NOTIFY 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, 13 Nov 2001 09:40:15 +0100 Hello, when a Contact header is included in the NOTIFY, does it update the Contact information which was included in the response to the SUBSCRIBE? Thanks Lachlan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 05:25:57 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18979 for ; Tue, 13 Nov 2001 05:25:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADANZCJ009531; Tue, 13 Nov 2001 05:23:35 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05030; Tue, 13 Nov 2001 05:25:06 -0500 (EST) 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 FAA05016 for ; Tue, 13 Nov 2001 05:24:35 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [63.113.40.50]) with SMTP; 13 Nov 2001 10:24:25 UT Received: from gbnewp0796m ([193.195.52.113]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 13 Nov 2001 10:26:57 +0000 From: "James Undery" To: "'Robert Sparks'" , "'Jonathan Rosenberg'" , Subject: RE: [Simple] Reacting to multiple sources of presence data (was 200v202) Message-ID: <00e001c16c2d$b8c179a0$7134c3c1@eu.ubiquity.net> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <9BF66EBF6BEFD942915B4D4D45C051F338E79A@DYN-TX-EXCH-001.dynamicsoft.com> Importance: Normal X-OriginalArrivalTime: 13 Nov 2001 10:26:57.0440 (UTC) FILETIME=[B8E49200:01C16C2D] 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, 13 Nov 2001 10:26:55 -0000 Content-Transfer-Encoding: 7bit inline > > > There have been a handful of proposed solutions, each > > > bringing their own set of additional problems. I think > > > these two capture the main flavors of the proposals: > > > > > > 1) Accept only the notifier who's 2xx was chosen by > > > the proxy mesh to be forwarded to the subscriber. > > > Ignore input from all other notifiers. > > > Rely on configuration of all the elements to provide > > > the "right" presence document. > > > (I think this is the currently documented solution) > > > Problems: > > > * Doesn't allow state aggregation (but maybe that > > > should be a domain-specific application and not > > > something we try to do generically in protocol) > > > > Another problem I pointed out is that the 2xx which was > > "chosen by the proxy mesh" may be a 202, and later be > > rejected, whereas one of the 2xx which was not chosen, is > > later accepted. However, its NOTIFY is discarded. > > I don't understand this scenario yet. What does it mean to be > later rejected or accepted? The scenario is subscription pending subject to authorisation, which may result in rejection or acceptance. > > > > > > > > 2) Accept all notifiers by springing subscriptions into > > > being on receiving NOTIFYs with matching dialog identifiers > > > (but unknown to-tags). Each such subscription exists > > > independently of the others, with its own lifetime and > > > route-set. Rely on configuration of all the elements > > > to provide the "right" set of notifiers. > > > Problems: > > > * How do you resolve conflicts during state composition? > > > * Is the DoS opportunity this creates acceptable? > > > > I'm not sure I understand the DoS opportunity. Can you elaborate? > > Assume you subscribe to me, and for some reason I decide to > take your client down. All I need to do is send some number > of NOTIFYs with different To: tags (preferably with very large > route-sets that you now have to maintain), continuing until you > run out of memory and die. This will require far less effort on > my part than simply trying to flood your network connection. This problem exists in a different form in case 1, where, I return a fake 200 with my own tag in the 200. You will never get a NOTIFY with a matching tag and it requires far less effort to prevent any of your subscriptions succeeding (perl and netcat stand a good chance of beating legitimate replies). Limiting the number of NOTIFIYs you accept for a given subscription is a simple way to limit your DoS attack for case 2 to being effective as the one I described above for case 1. > > > > > > * The configuration necessary to reach the "right" set > > > is very restrictive. (For instance, all the notifiers > > > must be behind the same number of challenging proxies). > > > > I don't see that at all. What has the number of proxies got > > to do with it? > > Consider the following topology > > notifier 1 > / > subscriber --- P1 > \ > P2 - notifier 2 > > Where P2 issues a 407. If notifier 1 issues a 2xx, you will > never be able to get presence information from notifier 2 - > you will never see its challenge. If you needed the information > from both notifer 1 and notifier 2 in order to be correct, the same > number of challenging proxies would have to exist on the path > from subscriber to notifier 1 and the path from subscriber to > notifier 2, or one of them will be left out in the cold. These issues have also been discussed on the SIPPING list, my proposed solution was to add an additional header to the NOTIFY that indicated subscription state. This helps with the 200 vs 202 issue and has an added bonus. If the state allows unauthenticated the subscription can be reissued to the notifier directly (using the route set) and individual subscriptions authenticated regardless of other notifiers returning 2xx. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 06:00:59 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19320 for ; Tue, 13 Nov 2001 06:00:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADAwSCJ009657; Tue, 13 Nov 2001 05:58:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05176; Tue, 13 Nov 2001 06:00:08 -0500 (EST) Received: from ubqgate02.lotus.com ([194.196.39.110]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05161; Tue, 13 Nov 2001 05:59:58 -0500 (EST) From: Avshalom@ubique.com Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) To: Jonathan Rosenberg Cc: Robert Sparks , "'simple@mailman.dynamicsoft.com'" , simple-admin@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: X-MIMETrack: Serialize by Router on shark/system/Ubique(Release 5.0.5 |September 22, 2000) at 13/11/2001 12:59:09 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: Tue, 13 Nov 2001 12:58:57 +0200 Maybe SUBSCRIBE should be treated as INVITE with three way handshake. It is actually a session in a sense. This way the subscriber will be able to choose from whom to accept the notifications. ------------------------- Avshalom Houri Software Architect, Lotus Sametime IBM Software Group Office +972-8-9409761 X123 Jonathan Rosenberg To: Robert Sparks , Sent by: "'simple@mailman.dynamicsoft.com'" simple-admin@mailman.dynam cc: icsoft.com Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) 13/11/2001 00:01 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, November 12, 2001 12:53 PM > To: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Reacting to multiple sources of presence data (was > 200v202) > > Given that: > > * A SUBSCRIBE may fork > * Multiple endpoints may accept the SUBSCRIBE > * These notifying endpoints may not have identical > presence documents to provide > > The root problem is: > * How do we reconcile the different documents? Yes, that is the essence of the problem. > > There have been a handful of proposed solutions, each > bringing their own set of additional problems. I think > these two capture the main flavors of the proposals: > > 1) Accept only the notifier who's 2xx was chosen by > the proxy mesh to be forwarded to the subscriber. > Ignore input from all other notifiers. > Rely on configuration of all the elements to provide > the "right" presence document. > (I think this is the currently documented solution) > Problems: > * Doesn't allow state aggregation (but maybe that > should be a domain-specific application and not > something we try to do generically in protocol) Another problem I pointed out is that the 2xx which was "chosen by the proxy mesh" may be a 202, and later be rejected, whereas one of the 2xx which was not chosen, is later accepted. However, its NOTIFY is discarded. > > 2) Accept all notifiers by springing subscriptions into > being on receiving NOTIFYs with matching dialog identifiers > (but unknown to-tags). Each such subscription exists > independently of the others, with its own lifetime and > route-set. Rely on configuration of all the elements > to provide the "right" set of notifiers. > Problems: > * How do you resolve conflicts during state composition? > * Is the DoS opportunity this creates acceptable? I'm not sure I understand the DoS opportunity. Can you elaborate? > * The configuration necessary to reach the "right" set > is very restrictive. (For instance, all the notifiers > must be behind the same number of challenging proxies). I don't see that at all. What has the number of proxies got to do with it? -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 Tue Nov 13 06:06:42 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19388 for ; Tue, 13 Nov 2001 06:06:42 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADB4OCJ009736; Tue, 13 Nov 2001 06:04:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05237; Tue, 13 Nov 2001 06:06:05 -0500 (EST) 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 GAA05226 for ; Tue, 13 Nov 2001 06:05:51 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [63.113.40.50]) with SMTP; 13 Nov 2001 11:05:39 UT Received: from gbnewp0796m ([193.195.52.113]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 13 Nov 2001 11:08:11 +0000 From: "James Undery" To: Cc: Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) Message-ID: <00ec01c16c33$7b946820$7134c3c1@eu.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: Importance: Normal X-OriginalArrivalTime: 13 Nov 2001 11:08:11.0660 (UTC) FILETIME=[7BA494C0:01C16C33] 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, 13 Nov 2001 11:08:10 -0000 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: simple-admin@mailman.dynamicsoft.com > [mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of > Avshalom@ubique.com > Maybe SUBSCRIBE should be treated as INVITE with three way > handshake. It is > actually a session in a sense. > This way the subscriber will be able to choose from whom to accept the > notifications. Please read the original thread "200 vs. 202" for why this is a REALLY bad idea. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 10:10:05 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28714 for ; Tue, 13 Nov 2001 10:10:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADF7SCJ011103; Tue, 13 Nov 2001 10:07:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05983; Tue, 13 Nov 2001 10:09:06 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05972 for ; Tue, 13 Nov 2001 10:08:55 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fADF8A411212; Tue, 13 Nov 2001 10:08:13 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA05066; Tue, 13 Nov 2001 10:06:36 -0500 (EST) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 10:07:54 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F93B4D77@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: Robert Sparks , Sean Olson , "'aki.niemi@nokia.com'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE 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, 13 Nov 2001 10:07:44 -0500 Hi, Robert: I just wanted to get the things clarified separating the layers: SIP's Session Layer and Application Layer. The second objective has been that the interpretation of all expire headers of all methods in the SIP layer should not create any conflicts when they are used in creating the SIP session (Let us now examine whether there are any conflicts or confusions in the SIP layer). Further comments inline [RRR] Many thanks for clarifications! Radhika -----Original Message----- From: Robert Sparks [mailto:rsparks@dynamicsoft.com] I'm not sure I understand your point. Yes, MESSAGE is a SIP method. There are no "same rules" to be considered. The core spec provides meaning to Expires for REGISTER, and (somewhat loosely) for INVITE, and those are different! It has no meaning for the other core methods (Expires is meaningless for BYE). New methods must specify meaning (if any) on their own. [RRR] Right. Each SIP methods clearly understands what the "expire header" means in the SIP layer. What the application will do with this information for each METHOD is outside the scope of SIP. For MESSAGE, I hold that the Expire header contains the period for which the content of the message should be considered valid, [RRR] Excellent! This is what the SIP layer will do in interpreting the "expire header" of the MESSAGE method. Let us stick to this in defining the "expire" header in the SIP session layer (as long as it does not have any conflicts with other expire headers in the SIP layer). and it should be up to the applications involved to decide what to do with expired messages, not the transport mechanism. Different applications are likely to need to make different choices. I may have a service where it is useful for me to know you invited me to lunch, even though I didn't see your invitation until it was too late to accept. [RRR] Agreed. The use of the expire header by the application is outside the scope of SIP. However, if people want to go further for standardization in building value-added applications, separate proposals can be made. (For example, MESSAGE sessions can be inter-related to the audio/video sessions [RRR] I just wanted to get the things clarified separating the layers: SIP's session Layer and Application Layer (Many Thanks for clarification!!) RjS > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, November 12, 2001 3:08 PM > To: Robert Sparks; Sean Olson; 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > Hi, Roberts: > > Is not that "MESSAGE" another method in SIP like INVITEs, > etc.? If so, why > do we not use the same rules (e.g., the interpretations can > be made in the > SIP layer)? > > Radhika > > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Monday, November 12, 2001 3:57 PM > To: Sean Olson; 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > Interpreting Expires to put bounds on the validity of the content > of the message is the correct thing to do. > > This is, however, information for the applications (or people) using > the message, not for the routing fabric. In particular, I don't think > it will make sense to reject "expired" messages at, say, a proxy. > Even at an endpoint, it should be up the the application running > above SIP to decide if it wants to process the "expired" message. > Taking that decision away (by requiring the SIP implementation > itself to reject the expired message) will do harm. > > RjS > > -----Original Message----- > From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > Sent: Monday, November 12, 2001 1:25 PM > To: 'aki.niemi@nokia.com' > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Expires in MESSAGE > > > > Hi, > > I see what you are saying. Should the "Expires: 0" be > interpreted as in a REGISTER or as in an INVITE? I was > thinking it would be treated the same as in an INVITE. > If you receive a MESSAGE with an Expires: that has passed > (or is literally zero), you return a 400 response and > "drop" the MESSAGE. > > /sean > > >Hi Sean, > > > >> This seems like the most logical interpretation for MESSAGE. > >> This would also seem to encompass the application you have in > >> mind below. > > > >I assumed the zero expiry is only defined for REGISTER and > >SUBSCRIBE, and > >maybe similar definitions for its semantics for MESSAGE would > >be needed? > > > >Cheers, > >Aki > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 10:14:45 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29008 for ; Tue, 13 Nov 2001 10:14:45 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADFCPCJ011237; Tue, 13 Nov 2001 10:12:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06042; Tue, 13 Nov 2001 10:14:05 -0500 (EST) 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 KAA06025 for ; Tue, 13 Nov 2001 10:13:25 -0500 (EST) 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 fADFBiCJ011210; Tue, 13 Nov 2001 10:11:44 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 10:13:05 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brazier Lachlan'" , Jonathan Rosenberg , "''simple@mailman.dynamicsoft.com' '" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] Contact header in 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: Tue, 13 Nov 2001 10:13:00 -0500 > -----Original Message----- > From: Brazier Lachlan [mailto:lachlan.brazier@siemens.at] > Sent: Tuesday, November 13, 2001 3:40 AM > To: 'Jonathan Rosenberg '; ''simple@mailman.dynamicsoft.com' ' > Cc: 'simple@mailman.dynamicsoft.com' > Subject: [Simple] Contact header in NOTIFY > > > Hello, > when a Contact header is included in the NOTIFY, does it > update the Contact > information which was included in the response to the SUBSCRIBE? Yes. Thats because 2xx to SUBSCRIBE creates a dialog, and the dialog rules in bis-05 talk about updating the contact on specific messages, which would include NOTIFY. -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 Tue Nov 13 10:54:58 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00779 for ; Tue, 13 Nov 2001 10:54:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADFmSCJ011814; Tue, 13 Nov 2001 10:48:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06179; Tue, 13 Nov 2001 10:50:06 -0500 (EST) 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 KAA06166 for ; Tue, 13 Nov 2001 10:49:53 -0500 (EST) 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 fADFmBCJ011802; Tue, 13 Nov 2001 10:48:11 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 10:49:32 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E7A2@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'James Undery'" , Robert Sparks , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) 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, 13 Nov 2001 10:49:17 -0500 > > > Another problem I pointed out is that the 2xx which was > > > "chosen by the proxy mesh" may be a 202, and later be > > > rejected, whereas one of the 2xx which was not chosen, is > > > later accepted. However, its NOTIFY is discarded. > > > > I don't understand this scenario yet. What does it mean to be > > later rejected or accepted? > > The scenario is subscription pending subject to > authorisation, which may > result in rejection or acceptance. Thanks - that was enough to jog my memory. > This problem exists in a different form in case 1, where, I > return a fake > 200 with my own tag in the 200. You will never get a NOTIFY Ok, we'll make sure to track this variant of DoS and document it if it exists in whatever solution we end up with. > These issues have also been discussed on the SIPPING list, my proposed > solution was to add an additional header to the NOTIFY that indicated > subscription state. This helps with the 200 vs 202 issue and > has an added > bonus. If the state allows unauthenticated the subscription > can be reissued > to the notifier directly (using the route set) and individual > subscriptions > authenticated regardless of other notifiers returning 2xx. Interesting - my apologies for not having absorbed that thread yet. There are some folks on this list that don't also subscribe to sipping - if there's more to your proposal than what you've summarized above, please elaborate. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 11:14:42 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02036 for ; Tue, 13 Nov 2001 11:14:42 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADG8VCJ012139; Tue, 13 Nov 2001 11:08:31 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06258; Tue, 13 Nov 2001 11:10:08 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06245 for ; Tue, 13 Nov 2001 11:09:56 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fADGAGA01797 for ; Tue, 13 Nov 2001 18:10:16 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 Nov 2001 18:09:34 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Nov 2001 18:09:34 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC5F@esebe013.NOE.Nokia.com> To: jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, rrroy@att.com, sean.olson@ericsson.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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, 13 Nov 2001 18:09:20 +0200 > I agree with Robert here. Proxies should ignore Expires in > MESSAGE. If a UA > wants to use it in some way, for example to limit the display > of an IM on > the screen, that is reasonable. I agree, for non-zero expirys. I'm looking for some extended meaning for the "Expires: 0" in MESSAGE. Like the "fetch" in SUBSCRIBE, or "remove contact" in REGISTER, it could have some added value for IM applications as well. For example, having zero expiry mean "don't store and forward me" sounds like something an IM inbox might find useful. Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 11:29:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03053 for ; Tue, 13 Nov 2001 11:29:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADGRRCJ012493; Tue, 13 Nov 2001 11:27:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06349; Tue, 13 Nov 2001 11:29:06 -0500 (EST) 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 LAA06338 for ; Tue, 13 Nov 2001 11:28:59 -0500 (EST) Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net via smtpd (for [63.113.40.50]) with SMTP; 13 Nov 2001 16:28:48 UT Received: from gbnewp0796m ([193.195.52.113]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.1600); Tue, 13 Nov 2001 16:31:19 +0000 From: "James Undery" To: "'Robert Sparks'" , "'Jonathan Rosenberg'" , Subject: RE: [Simple] Reacting to multiple sources of presence data (was 200v202) Message-ID: <014b01c16c60$9fa97e30$7134c3c1@eu.ubiquity.net> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <9BF66EBF6BEFD942915B4D4D45C051F338E7A2@DYN-TX-EXCH-001.dynamicsoft.com> Importance: Normal X-OriginalArrivalTime: 13 Nov 2001 16:31:19.0569 (UTC) FILETIME=[9FBCB810:01C16C60] 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, 13 Nov 2001 16:31:18 -0000 Content-Transfer-Encoding: 7bit > > These issues have also been discussed on the SIPPING list, > my proposed > > solution was to add an additional header to the NOTIFY that > indicated > > subscription state. This helps with the 200 vs 202 issue and > > has an added > > bonus. If the state allows unauthenticated the subscription > > can be reissued > > to the notifier directly (using the route set) and individual > > subscriptions > > authenticated regardless of other notifiers returning 2xx. > > Interesting - my apologies for not having absorbed that thread > yet. There are some folks on this list that don't also subscribe > to sipping - if there's more to your proposal than what you've > summarized above, please elaborate. Basically the problem is to emulate INVITE behaviour (without breaking rfc2543), by that I mean be able to handle multiple subscriptions even though only a single 2xx response is recieved. The problem is multiple PUAs may respond with a mixture of 200 and 202 responses, yet the subscriber only recieves a single 2xx response. My suggestion was to include subscription state (Via a header) in the NOTIFY that says if subscription is pending or authorised. In a rambling post I also thought (whilst posting) that this header could also be used to solve the case when a 401 is generated by the PUA. i.e. give the header an additional un-authenticated state. This would mean that immediate NOTIFYs would be generated for 2xxs and optionally (PUA dependent) 401s. On receiving a NOTIFY with an un-authenticated state the subscriber could reSUBSCRIBE to the PUA even if it had received 2xxs from other locations. (For a use for this think about sip:james@ubiquity.net forking to sip:10.0.0.1 and sip:james@mobile.phone where "mobile.phone" is a different domain to "ubiquity.net" and requires authentication for presence where ubiquity do not.) However, there are a number of problems though, firstly if the PUA did this it would be generating state for un-authenticated requests; secondly I'd like to see the rules for reSUBSCRIBEs change to allow them to follow the route set for efficiency. Anyway even though I am not totally convinced myself, it might be worth considering as an optional feature. James _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 12:26:55 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06706 for ; Tue, 13 Nov 2001 12:26:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADHOSCJ013335; Tue, 13 Nov 2001 12:24:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06573; Tue, 13 Nov 2001 12:26:06 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06561 for ; Tue, 13 Nov 2001 12:25:36 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fADHPAP00237; Tue, 13 Nov 2001 11:25:10 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fADHPAt15180; Tue, 13 Nov 2001 11:25:10 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA12650; Tue, 13 Nov 2001 11:25:10 -0600 (CST) Reply-To: To: "'Robert Sparks'" , "Jonathan Rosenberg" , Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) Message-ID: <61D824C63B99D311975E00508B0CC98502C66C29@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E79A@DYN-TX-EXCH-001.dynamicsoft.com> 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, 13 Nov 2001 11:25:09 -0600 Content-Transfer-Encoding: 7bit > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > Assume you subscribe to me, and for some reason I decide to > take your client down. All I need to do is send some number > of NOTIFYs with different To: tags (preferably with very large > route-sets that you now have to maintain), continuing until you > run out of memory and die. This will require far less effort on > my part than simply trying to flood your network connection. Authentication. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 12:34:33 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07139 for ; Tue, 13 Nov 2001 12:34:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADHSTCJ013438; Tue, 13 Nov 2001 12:28:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06609; Tue, 13 Nov 2001 12:30:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06591 for ; Tue, 13 Nov 2001 12:29:57 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fADHTSP02686; Tue, 13 Nov 2001 11:29:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fADHTSD13228; Tue, 13 Nov 2001 11:29:28 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA12740; Tue, 13 Nov 2001 11:29:27 -0600 (CST) Reply-To: To: , , , , "Sean Olson \(EUS\)" <> Cc: Subject: RE: [Simple] Expires in MESSAGE Message-ID: <61D824C63B99D311975E00508B0CC98502C66C2A@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC5F@esebe013.NOE.Nokia.com> 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, 13 Nov 2001 11:29:26 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > I'm looking for some extended meaning for the "Expires: 0" in > MESSAGE. Like > the "fetch" in SUBSCRIBE, or "remove contact" in REGISTER, it > could have > some added value for IM applications as well. > > For example, having zero expiry mean "don't store and forward > me" sounds > like something an IM inbox might find useful. Please, don't special case zero. I agree 100% with Robert and Jonathan: Expires should be treated exactly like it is for e-mail. In other words, the client may (or may not) choose to render this content in some special fashion to indicate to the user that the message is no longer relevant. Expires for MESSAGE should not have transport semantics. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 12:36:43 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07281 for ; Tue, 13 Nov 2001 12:36:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADHUYCJ013525; Tue, 13 Nov 2001 12:30:34 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06636; Tue, 13 Nov 2001 12:32:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06600 for ; Tue, 13 Nov 2001 12:30:05 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fADHK8P27546; Tue, 13 Nov 2001 11:20:08 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fADHK7t12061; Tue, 13 Nov 2001 11:20:07 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA12552; Tue, 13 Nov 2001 11:20:07 -0600 (CST) Reply-To: To: "'Robert Sparks'" , "'James Undery'" , "Jonathan Rosenberg" , "'Brian Stucker'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'adam.roach'" , "'ext Paul Kyzivat'" Cc: "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C28@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F338E76F@DYN-TX-EXCH-001.dynamicsoft.com> 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, 13 Nov 2001 11:20:05 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > that will refresh the subscription. That request will get to > exactly one of the notifiers. Okay; apparently, I need to clarify this in the SUB/NOT draft: each NOTIFY is intended to set up a unique route. Each route corresponds to a subscription. Each subscription will be refreshed individually. If I send a SUBSCRIBE to B and it forks to B1 and B2, I'll get a 2xx from (say) B1. I will get a NOTIFY from B1 and B2. These NOTIFY requests each set up a route. They also communicate the subscription duration in the "Subscription-Expires" header. When I go to refresh the subscriptions (which may or may not occur at the same time), I will send *two* SUBSCRIBE messages: one to B1 (using whatever route set B1's NOTIFY established), and one to B2 (using whatever route set B2's NOTIFY established). I'll try to make this less prone to misinterpretation for -02. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 13:04:00 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09178 for ; Tue, 13 Nov 2001 13:04:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADI1cCJ013940; Tue, 13 Nov 2001 13:01:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06756; Tue, 13 Nov 2001 13:03:10 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06745 for ; Tue, 13 Nov 2001 13:02:20 -0500 (EST) From: aki.niemi@nokia.com Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fADI2eA19881 for ; Tue, 13 Nov 2001 20:02:41 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 Nov 2001 20:01:59 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Tue, 13 Nov 2001 20:02:00 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC60@esebe013.NOE.Nokia.com> To: adam.roach@ericsson.com, jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, rrroy@att.com Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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, 13 Nov 2001 20:01:55 +0200 Hi Adam, > > I'm looking for some extended meaning for the "Expires: 0" in > > MESSAGE. Like > > the "fetch" in SUBSCRIBE, or "remove contact" in REGISTER, it > > could have > > some added value for IM applications as well. > > > > For example, having zero expiry mean "don't store and forward > > me" sounds > > like something an IM inbox might find useful. > > Please, don't special case zero. I don't see the harm in doing so. Registrars and PAs handle zero in a special way. Why not IM servers? > I agree 100% with Robert and Jonathan: Expires should be treated > exactly like it is for e-mail. In other words, the client may > (or may not) choose to render this content in some special fashion > to indicate to the user that the message is no longer relevant. > > Expires for MESSAGE should not have transport semantics. I fully agree with this. I'm not trying to reuse the Expires as message TTL in a SIP network. It should only have meaning to the UA. But it feels like a missed opportunity here. If it doesn't have any extended meaning, the zero expiry will be ambiguous -- after all, if the message has zero expiry, why send it? Cheers, Aki _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 13:53:57 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12270 for ; Tue, 13 Nov 2001 13:53:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADIpUCJ014514; Tue, 13 Nov 2001 13:51:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06935; Tue, 13 Nov 2001 13:53:06 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06924 for ; Tue, 13 Nov 2001 13:52:24 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fADIp7107053; Tue, 13 Nov 2001 13:51:07 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD56259 (AUTH pkyzivat); Tue, 13 Nov 2001 13:53:24 -0500 (EST) Message-ID: <3BF16B29.39C4F223@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Robert Sparks'" , "'James Undery'" , Jonathan Rosenberg , "'Brian Stucker'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" Subject: Re: [Simple] 200 vs. 202 References: <61D824C63B99D311975E00508B0CC98502C66C28@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii 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: Tue, 13 Nov 2001 13:49:13 -0500 Content-Transfer-Encoding: 7bit With this developing interpretation, it seems that the 2xx response to the original subscriber is of little significance - there can be a variety of NOTIFYs coming back from different places, and all of them may be important. This is both similar and different than a forked INVITE: - in the case of INVITE, while it is possible to end up with multiple dialogs, in general the desire is for only one. A forking proxy will typically try to prevent multiple dialogs by sending CANCELs after the first 2xx response. Because of this, retransmission of the invite on other forks isn't important. - in the case of SUBSCRIBE, if it is forked, it is likely that each and every fork may have something unique to contribute. Therefore it is important that the normal efforts to achieve reliable delivery be applied to each fork. Clearly this won't be the case if CANCELs are sent, as they are for INVITE. (Whether this should happen seems to be an open issue in bis5.) Even if CANCELs are not sent for extra forks after receiving a 2xx, will the proxy continue to retransmit on the other forks until it gets a response, or might a proxy simply cease retransmissions on other legs once one leg has succeeded? If they are dropped, some important participants may be missed. Even if retransmissions are done, the original subscriber will not hear about failures after an initial success, and so will not be aware of what potentially important information may be missing. If dealing with multiple PAs is an obligation of the subscribing client, then I think that client needs to be given the tools to do it right. One solution would be to require that if subscribe must be forked, that a proxy simply return a 300 with the multiple Contacts rather than attempting to do the fork itself. At least then it wouldn't get in the way of doing a proper job. Paul adam.roach@ericsson.com wrote: > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Okay; apparently, I need to clarify this in the SUB/NOT draft: > each NOTIFY is intended to set up a unique route. Each route > corresponds to a subscription. Each subscription will be refreshed > individually. > > If I send a SUBSCRIBE to B and it forks to B1 and B2, I'll get a > 2xx from (say) B1. I will get a NOTIFY from B1 and B2. These > NOTIFY requests each set up a route. They also communicate the > subscription duration in the "Subscription-Expires" header. > > When I go to refresh the subscriptions (which may or may not > occur at the same time), I will send *two* SUBSCRIBE messages: > one to B1 (using whatever route set B1's NOTIFY established), > and one to B2 (using whatever route set B2's NOTIFY established). > > I'll try to make this less prone to misinterpretation for -02. > > /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 14:05:54 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12792 for ; Tue, 13 Nov 2001 14:05:54 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADJ3SCJ014713; Tue, 13 Nov 2001 14:03:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06995; Tue, 13 Nov 2001 14:05:06 -0500 (EST) 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 OAA06982 for ; Tue, 13 Nov 2001 14:04:20 -0500 (EST) 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 fADJ2fCJ014698; Tue, 13 Nov 2001 14:02:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 14:04:00 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E7A4@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'adam.roach@ericsson.com'" , Robert Sparks , Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Reacting to multiple sources of presence data (was 2 00v202) 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, 13 Nov 2001 14:03:55 -0500 Elaborate. (note that the subscription is legitimate - if I can provide credentials that you will accept for one notify, I can provide them for N notifies). RjS > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Tuesday, November 13, 2001 11:25 AM > To: 'Robert Sparks'; Jonathan Rosenberg; > simple@mailman.dynamicsoft.com > Subject: RE: [Simple] Reacting to multiple sources of > presence data (was > 2 00v202) > > > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > Assume you subscribe to me, and for some reason I decide to > > take your client down. All I need to do is send some number > > of NOTIFYs with different To: tags (preferably with very large > > route-sets that you now have to maintain), continuing until you > > run out of memory and die. This will require far less effort on > > my part than simply trying to flood your network connection. > > Authentication. > > /a > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 14:08:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12917 for ; Tue, 13 Nov 2001 14:08:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADJ6SCJ014802; Tue, 13 Nov 2001 14:06:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07030; Tue, 13 Nov 2001 14:08:06 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07019 for ; Tue, 13 Nov 2001 14:07:31 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fADJ6F108150; Tue, 13 Nov 2001 14:06:15 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD56415 (AUTH pkyzivat); Tue, 13 Nov 2001 14:08:30 -0500 (EST) Message-ID: <3BF16EB3.BE8A24BE@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: adam.roach@ericsson.com, jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, rrroy@att.com, simple@mailman.dynamicsoft.com Subject: Re: [Simple] Expires in MESSAGE References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC60@esebe013.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii 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: Tue, 13 Nov 2001 14:04:19 -0500 Content-Transfer-Encoding: 7bit Aki, There really isn't any special semantic for 0 in REGISTER or SUBSCRIBE, in each case the behavior for 0 is simply the natural degenerate case for the general semantics of the message in a UAS when it expires. In the case of MESSAGE, there aren't any semantics in draft-ietf-simple-im-01 that can be reduced to a degenerate form. I suppose you could propose changes that would tell the UAS to suppress display of a MESSAGE if it cannot be displayed until after it has expired. But I doubt that is a good thing to mandate. Paul Kyzivat Cisco Systems aki.niemi@nokia.com wrote: > > Hi Adam, > > > > I'm looking for some extended meaning for the "Expires: 0" in > > > MESSAGE. Like > > > the "fetch" in SUBSCRIBE, or "remove contact" in REGISTER, it > > > could have > > > some added value for IM applications as well. > > > > > > For example, having zero expiry mean "don't store and forward > > > me" sounds > > > like something an IM inbox might find useful. > > > > Please, don't special case zero. > > I don't see the harm in doing so. Registrars and PAs handle zero in a > special way. Why not IM servers? > > > I agree 100% with Robert and Jonathan: Expires should be treated > > exactly like it is for e-mail. In other words, the client may > > (or may not) choose to render this content in some special fashion > > to indicate to the user that the message is no longer relevant. > > > > Expires for MESSAGE should not have transport semantics. > > I fully agree with this. I'm not trying to reuse the Expires as message TTL > in a SIP network. It should only have meaning to the UA. > > But it feels like a missed opportunity here. If it doesn't have any extended > meaning, the zero expiry will be ambiguous -- after all, if the message has > zero expiry, why send it? > > Cheers, > Aki > _______________________________________________ > 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 Tue Nov 13 14:21:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13534 for ; Tue, 13 Nov 2001 14:21:51 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADJJSCJ015042; Tue, 13 Nov 2001 14:19:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07097; Tue, 13 Nov 2001 14:21:06 -0500 (EST) 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 OAA07085 for ; Tue, 13 Nov 2001 14:20:12 -0500 (EST) 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 NAA04876 for ; Tue, 13 Nov 2001 13:19:50 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 13 Nov 2001 13:12:37 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 13:18:32 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0ECA4750@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Paul Kyzivat , adam.roach@ericsson.com Cc: "'Robert Sparks'" , "'James Undery'" , Jonathan Rosenberg , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'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_01C16C77.F7D62880" 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: Tue, 13 Nov 2001 13:18:25 -0600 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_01C16C77.F7D62880 Content-Type: text/plain; charset="iso-8859-1" Good points, however, I would change the wording a little bit. It should be up to the network whether or not it wants to send back a 300 to the client. Forcing the client to fork seems too harsh a requirement. In the -03 draft it's already stipulated that if there are multiple PA's representing a presentity, that they MUST all have the same "picture" of the user's presence. So in terms of what you're going to get back from any given PA, is dealer's choice to the originating subscriber. It makes no difference. Forking is just looking for which one is available the quickest, and nothing more. The proxy may not know which contacts are really PA's. All we've said is if you want to be a PA, mark your contact using the caller preferences in your registration. There are any number of other event packages that could lay the same claim to including a methods="SUBSCRIBE" to identify the willingness of the client to support some sort of subscription mechanism (not just presence). This could cause forking to occur, but some (or none) of the clients that got forked to support subscriptons to the presence event package. Once again, sending back a 300 doesn't help us any. If we leave the stake in the ground that presence information should not be aggregated at the watcher, because policy is difficult at best to apply in this situation, then we need to ensure one of two things: - Making sure that there is one, and only one, PA (which is what ICQ, AOL, MSN, etc. have been doing for a long time now). - Making sure that if there is going to be more than one PA, either the results are always aggregated somewhere in the network (for policy decisions) or that all of the PA's are kept in sync (which is extremely difficult to do). If we solve either of these problems, not only do we solve the forking issue with presence (because it either won't matter which response you get back, or you'll only ever get one positive response). I'd argue it's far easier to just say "there shall be only one" and build the architecture around that. When you take into account that the SUBSCRIBE may get forked by an ignorant proxy somewhere to clients that might not support SUBSCRIBE (405), or might not support presence subscriptions (489), or might support presence subscriptions, but don't want to authorize the user (202), or do want to authorize the user (200) you run into a huge mess. How much are we really buying ourselves by trying to allow multiple, synchronized (as is in -03) PA's instead of simply having a single, *logical* (not necessarily physical) PA in the network? Cheers, Brian -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, November 13, 2001 12:49 PM To: adam.roach@ericsson.com Cc: 'Robert Sparks'; 'James Undery'; Jonathan Rosenberg; Stucker, Brian [NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: Re: [Simple] 200 vs. 202 With this developing interpretation, it seems that the 2xx response to the original subscriber is of little significance - there can be a variety of NOTIFYs coming back from different places, and all of them may be important. This is both similar and different than a forked INVITE: - in the case of INVITE, while it is possible to end up with multiple dialogs, in general the desire is for only one. A forking proxy will typically try to prevent multiple dialogs by sending CANCELs after the first 2xx response. Because of this, retransmission of the invite on other forks isn't important. - in the case of SUBSCRIBE, if it is forked, it is likely that each and every fork may have something unique to contribute. Therefore it is important that the normal efforts to achieve reliable delivery be applied to each fork. Clearly this won't be the case if CANCELs are sent, as they are for INVITE. (Whether this should happen seems to be an open issue in bis5.) Even if CANCELs are not sent for extra forks after receiving a 2xx, will the proxy continue to retransmit on the other forks until it gets a response, or might a proxy simply cease retransmissions on other legs once one leg has succeeded? If they are dropped, some important participants may be missed. Even if retransmissions are done, the original subscriber will not hear about failures after an initial success, and so will not be aware of what potentially important information may be missing. If dealing with multiple PAs is an obligation of the subscribing client, then I think that client needs to be given the tools to do it right. One solution would be to require that if subscribe must be forked, that a proxy simply return a 300 with the multiple Contacts rather than attempting to do the fork itself. At least then it wouldn't get in the way of doing a proper job. Paul adam.roach@ericsson.com wrote: > > > -----Original Message----- > > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > > > > The problem is not with the NOTIFY, its with the reSUBSCRIBE > > that will refresh the subscription. That request will get to > > exactly one of the notifiers. > > Okay; apparently, I need to clarify this in the SUB/NOT draft: > each NOTIFY is intended to set up a unique route. Each route > corresponds to a subscription. Each subscription will be refreshed > individually. > > If I send a SUBSCRIBE to B and it forks to B1 and B2, I'll get a > 2xx from (say) B1. I will get a NOTIFY from B1 and B2. These > NOTIFY requests each set up a route. They also communicate the > subscription duration in the "Subscription-Expires" header. > > When I go to refresh the subscriptions (which may or may not > occur at the same time), I will send *two* SUBSCRIBE messages: > one to B1 (using whatever route set B1's NOTIFY established), > and one to B2 (using whatever route set B2's NOTIFY established). > > I'll try to make this less prone to misinterpretation for -02. > > /a ------_=_NextPart_001_01C16C77.F7D62880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Good points, however, I would change the wording a = little bit. It should be up to the network whether or not it wants to = send back a 300 to the client. Forcing the client to fork seems too = harsh a requirement. In the -03 draft it's already stipulated that if = there are multiple PA's representing a presentity, that they MUST all = have the same "picture" of the user's presence. So in terms = of what you're going to get back from any given PA, is dealer's choice = to the originating subscriber. It makes no difference. Forking is just = looking for which one is available the quickest, and nothing = more.

The proxy may not know which contacts are really = PA's. All we've said is if you want to be a PA, mark your contact using = the caller preferences in your registration. There are any number of = other event packages that could lay the same claim to including a = methods=3D"SUBSCRIBE" to identify the willingness of the = client to support some sort of subscription mechanism (not just = presence). This could cause forking to occur, but some (or none) of the = clients that got forked to support subscriptons to the presence event = package. Once again, sending back a 300 doesn't help us any.

If we leave the stake in the ground that presence = information should not be aggregated at the watcher, because policy is = difficult at best to apply in this situation, then we need to ensure = one of two things:

- Making sure that there is one, and only one, PA = (which is what ICQ, AOL, MSN, etc. have been doing for a long time = now).

- Making sure that if there is going to be more than = one PA, either the results are always aggregated somewhere in the = network (for policy decisions) or that all of the PA's are kept in sync = (which is extremely difficult to do).

If we solve either of these problems, not only do we = solve the forking issue with presence (because it either won't matter = which response you get back, or you'll only ever get one positive = response). I'd argue it's far easier to just say "there shall be = only one" and build the architecture around that. When you take = into account that the SUBSCRIBE may get forked by an ignorant proxy = somewhere to clients that might not support SUBSCRIBE (405), or might = not support presence subscriptions (489), or might support presence = subscriptions, but don't want to authorize the user (202), or do want = to authorize the user (200) you run into a huge mess.

How much are we really buying ourselves by trying to = allow multiple, synchronized (as is in -03) PA's instead of simply = having a single, *logical* (not necessarily physical) PA in the = network?

Cheers,

Brian

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=
Sent: Tuesday, November 13, 2001 12:49 PM
To: adam.roach@ericsson.com
Cc: 'Robert Sparks'; 'James Undery'; Jonathan = Rosenberg; Stucker, Brian
[NGB:B635:EXCH]; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai = (c)'; 'Brazier
Lachlan'; 'simple'
Subject: Re: [Simple] 200 vs. 202


With this developing interpretation, it seems that = the 2xx response to
the original subscriber is of little significance - = there can be a
variety of NOTIFYs coming back from different = places, and all of them
may be important. This is both similar and different = than a forked
INVITE:

- in the case of INVITE, while it is possible to end = up with multiple
dialogs, in general the desire is for only one. A = forking proxy will
typically try to prevent multiple dialogs by sending = CANCELs after the
first 2xx response. Because of this, retransmission = of the invite on
other forks isn't important.

- in the case of SUBSCRIBE, if it is forked, it is = likely that each and
every fork may have something unique to contribute. = Therefore it is
important that the normal efforts to achieve = reliable delivery be
applied to each fork. Clearly this won't be the case = if CANCELs are
sent, as they are for INVITE. (Whether this should = happen seems to be an
open issue in bis5.) Even if CANCELs are not sent = for extra forks after
receiving a 2xx, will the proxy continue to = retransmit on the other
forks until it gets a response, or might a proxy = simply cease
retransmissions on other legs once one leg has = succeeded? If they are
dropped, some important participants may be missed. = Even if
retransmissions are done, the original subscriber = will not hear about
failures after an initial success, and so will not = be aware of what
potentially important information may be = missing.

If dealing with multiple PAs is an obligation of the = subscribing client,
then I think that client needs to be given the tools = to do it right. One
solution would be to require that if subscribe must = be forked, that a
proxy simply return a 300 with the multiple Contacts = rather than
attempting to do the fork itself. At least then it = wouldn't get in the
way of doing a proper job.

        Paul

adam.roach@ericsson.com wrote:
>
> > -----Original Message-----
> > From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> >
> > The problem is not with the NOTIFY, its = with the reSUBSCRIBE
> > that will refresh the subscription. That = request will get to
> > exactly one of the notifiers.
>
> Okay; apparently, I need to clarify this in the = SUB/NOT draft:
> each NOTIFY is intended to set up a unique = route. Each route
> corresponds to a subscription. Each = subscription will be refreshed
> individually.
>
> If I send a SUBSCRIBE to B and it forks to B1 = and B2, I'll get a
> 2xx from (say) B1. I will get a NOTIFY from B1 = and B2. These
> NOTIFY requests each set up a route. They also = communicate the
> subscription duration in the = "Subscription-Expires" header.
>
> When I go to refresh the subscriptions (which = may or may not
> occur at the same time), I will send *two* = SUBSCRIBE messages:
> one to B1 (using whatever route set B1's NOTIFY = established),
> and one to B2 (using whatever route set B2's = NOTIFY established).
>
> I'll try to make this less prone to = misinterpretation for -02.
>
> /a

------_=_NextPart_001_01C16C77.F7D62880-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 14:31:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14046 for ; Tue, 13 Nov 2001 14:31:46 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADJTQCJ015252; Tue, 13 Nov 2001 14:29:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07175; Tue, 13 Nov 2001 14:31:05 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07164 for ; Tue, 13 Nov 2001 14:30:43 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fADJU9T02003; Tue, 13 Nov 2001 13:30:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fADJU9920662; Tue, 13 Nov 2001 13:30:09 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id NAA23651; Tue, 13 Nov 2001 13:30:08 -0600 (CST) Reply-To: To: , , , , Cc: Subject: RE: [Simple] Expires in MESSAGE Message-ID: <61D824C63B99D311975E00508B0CC98502C66C2C@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FEC60@esebe013.NOE.Nokia.com> 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, 13 Nov 2001 13:30:08 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com] > > > > > Please, don't special case zero. > > I don't see the harm in doing so. Registrars and PAs handle zero in a > special way. Why not IM servers? Actually, if you study the behavior, they don't. That's what's so extremely spiffy about the way that registrars and PAs work. I've made this point before, but I'll repeat it for your benefit. If want to unregister, I can send a REGISTER with an "Expires" of "1" and wait a second. I can send a REGISTER with an "Expires" of "2" and wait two seconds. Or, I can send a REGISTER with an "Expires" of "0" and wait zero seconds. It all works. Zero isn't a special case at all. This all becomes somewhat more obvious when you go to implement a registrar or PA. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 15:22:28 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15475 for ; Tue, 13 Nov 2001 15:22:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADKKSCJ015980; Tue, 13 Nov 2001 15:20:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07348; Tue, 13 Nov 2001 15:22:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07336 for ; Tue, 13 Nov 2001 15:21:27 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fADKFaP05208; Tue, 13 Nov 2001 14:15:36 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fADKFaY25892; Tue, 13 Nov 2001 14:15:36 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id OAA27225; Tue, 13 Nov 2001 14:15:35 -0600 (CST) Reply-To: To: "'Paul Kyzivat'" , Cc: "'Robert Sparks'" , "'James Undery'" , "Jonathan Rosenberg" , "'Brian Stucker'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C2E@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3BF16B29.39C4F223@cisco.com> 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, 13 Nov 2001 14:15:35 -0600 Content-Transfer-Encoding: 7bit > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > If dealing with multiple PAs is an obligation of the > subscribing client, > then I think that client needs to be given the tools to do it > right. One > solution would be to require that if subscribe must be forked, that a > proxy simply return a 300 with the multiple Contacts rather than > attempting to do the fork itself. At least then it wouldn't get in the > way of doing a proper job. Forking proxies -- the ones that have already been developed, sold, delivered, and put in service -- don't know SUBSCRIBE from INFO, MESSAGE, or FOO. We can't impose ex-post-facto requirements on them. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 15:33:32 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15850 for ; Tue, 13 Nov 2001 15:33:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADKVTCJ016131; Tue, 13 Nov 2001 15:31:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07404; Tue, 13 Nov 2001 15:33:07 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07393 for ; Tue, 13 Nov 2001 15:32:44 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fADKUOC07375; Tue, 13 Nov 2001 15:30:39 -0500 (EST) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA00388; Tue, 13 Nov 2001 15:30:49 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 15:30:20 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F93B50B3@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: Brian Stucker , Paul Kyzivat , adam.roach@ericsson.com Cc: "'Robert Sparks'" , "'James Undery'" , Jonathan Rosenberg , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" 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, 13 Nov 2001 15:29:31 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, November 13, 2001 2:18 PM To: Paul Kyzivat; adam.roach@ericsson.com Cc: 'Robert Sparks'; 'James Undery'; Jonathan Rosenberg; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 .... If we leave the stake in the ground that presence information should not be aggregated at the watcher, because policy is difficult at best to apply in this situation, then we need to ensure one of two things: - Making sure that there is one, and only one, PA (which is what ICQ, AOL, MSN, etc. have been doing for a long time now). [Roy, Radhika R, ALARC] Are you suggesting this simplified solution because, as Paul has pointed out, there is a fundamental difference the way forking works in INVITE and SUBSCRIBE/NOTIFY method? Is this solution due to the forking problems (not to be satisfactorily addressed in SUBSCRIBE/NOTIFY method)? - Making sure that if there is going to be more than one PA, either the results are always aggregated somewhere in the network (for policy decisions) or that all of the PA's are kept in sync (which is extremely difficult to do). [Roy, Radhika R, ALARC] This is what the end results may look like. I wonder how can we communicate among multiple PAs to synchronize states? We may need to change the forking behavior in SUBSCRIBE/NOTIFY if the present suggested method is not satisfactory. ... _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 16:05:27 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16784 for ; Tue, 13 Nov 2001 16:05:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADL3TCJ016562; Tue, 13 Nov 2001 16:03:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07517; Tue, 13 Nov 2001 16:05:07 -0500 (EST) 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 QAA07504 for ; Tue, 13 Nov 2001 16:04:24 -0500 (EST) 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 PAA12459 for ; Tue, 13 Nov 2001 15:04:04 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 13 Nov 2001 14:56:51 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 Nov 2001 15:02:44 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0ECFCCBE@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Roy, Radhika R, ALCTA" , Paul Kyzivat , adam.roach@ericsson.com Cc: "'Robert Sparks'" , "'James Undery'" , Jonathan Rosenberg , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'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_01C16C86.8744E020" 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: Tue, 13 Nov 2001 15:02:39 -0600 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_01C16C86.8744E020 Content-Type: text/plain; charset="iso-8859-1" Radhika, I am suggesting this simplified approach, and I have done so a number of times before for various reasons. It solves a lot of problems in one fell swoop in my mind, and isn't giving up a whole lot in the process. Arguing the differences in the way forking for INVITE differs from SUBSCRIBE/NOTIFY doesn't seem all that productive to me, because it's comparing apples to oranges, and any solutions suggested by doing so lead to mechanisms that would cause us to have to essentially create SIP/2.1 to handle, or are so awkward that the medicene is arguably worse than the disease. INVITE is not an isomorphic request, and ACK has caused headaches for implementors as well. Ask anyone working on early media what the three-way handshake model that INVITE has done to the complexity of what is otherwise a very straight-forward message sequence. How many drafts are out there because of that little interaction alone? The solution to have one, and only one, PA, is related to the forking problem, yes, but so much more: - Many other implementations that have MILLIONS of subscribers have turned to allowing only 1 PA to solve this problem, is obviously sufficient to meet customer expectations. - Go out and look at the billing models for these IM services that have client-controlled topologies. They can't. If the clients can be their own presence agent, then it makes it next to impossible to charge them for that service. All you can do is charge for connectivity, and that's it. - It's really hard to build presence based services in the network (like network based call screening) unless you provision the client with potentially a great deal of information about the provider network, and expect the customer to leave their device on 24x7. Having more than one presence user agent for a presence agent makes perfect sense. It's a huge advantage that SIMPLE has over the other IM presence implementations out there today. Further decomposition, however, doesn't really add anything unless it is your desire to have a network full of extremely intelligent clients that are always on, and have flat-rate high-speed access to the network 24x7. To answer your second question, let's say that's what we want. On top of all the trouble we have to go through to synchronize a single presence agent finite state machine with the FSM's of all the watchers, let's make things that much more interesting, introduce a plethora of race conditions and error scenarios, and try synchronizing a fully connected graph of N number of presence agent FSM's to M number of watchers. Even if it were possible to sufficiently squash all of the race conditions and error scenarios, aren't we really pushing it a little too far to try to do so? Presence and SUBSCRIBE/NOTIFY is already the near perfect denial-of-service attack due to the messaging demands it can place on a network. Why inflict N * M number of messages, when you can do perfectly well, offer more services more reliably with lower demand on the end user, probably at a cheaper price (because the terminals don't have to be as fancy, and OA&M operations are centralized), and have 1 * M number of messages. Thoughts? Brian Stucker Nortel Networks -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] If we leave the stake in the ground that presence information should not be aggregated at the watcher, because policy is difficult at best to apply in this situation, then we need to ensure one of two things: - Making sure that there is one, and only one, PA (which is what ICQ, AOL, MSN, etc. have been doing for a long time now). [Roy, Radhika R, ALARC] Are you suggesting this simplified solution because, as Paul has pointed out, there is a fundamental difference the way forking works in INVITE and SUBSCRIBE/NOTIFY method? Is this solution due to the forking problems (not to be satisfactorily addressed in SUBSCRIBE/NOTIFY method)? - Making sure that if there is going to be more than one PA, either the results are always aggregated somewhere in the network (for policy decisions) or that all of the PA's are kept in sync (which is extremely difficult to do). [Roy, Radhika R, ALARC] This is what the end results may look like. I wonder how can we communicate among multiple PAs to synchronize states? We may need to change the forking behavior in SUBSCRIBE/NOTIFY if the present suggested method is not satisfactory. ... ------_=_NextPart_001_01C16C86.8744E020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Radhika,

I am suggesting this simplified approach, and I have = done so a number of times before for various reasons. It solves a lot = of problems in one fell swoop in my mind, and isn't giving up a whole = lot in the process. Arguing the differences in the way forking for = INVITE differs from SUBSCRIBE/NOTIFY doesn't seem all that productive = to me, because it's comparing apples to oranges, and any solutions = suggested by doing so lead to mechanisms that would cause us to have to = essentially create SIP/2.1 to handle, or are so awkward that the = medicene is arguably worse than the disease.

INVITE is not an isomorphic request, and ACK has = caused headaches for implementors as well. Ask anyone working on early = media what the three-way handshake model that INVITE has done to the = complexity of what is otherwise a very straight-forward message = sequence. How many drafts are out there because of that little = interaction alone?

The solution to have one, and only one, PA, is = related to the forking problem, yes, but so much more:

- Many other implementations that have MILLIONS of = subscribers have turned to allowing only 1 PA to solve this problem, is = obviously sufficient to meet customer expectations.

- Go out and look at the billing models for these IM = services that have client-controlled topologies. They can't. If the = clients can be their own presence agent, then it makes it next to = impossible to charge them for that service. All you can do is charge = for connectivity, and that's it.

- It's really hard to build presence based services = in the network (like network based call screening) unless you provision = the client with potentially a great deal of information about the = provider network, and expect the customer to leave their device on = 24x7.

Having more than one presence user agent for a = presence agent makes perfect sense. It's a huge advantage that SIMPLE = has over the other IM presence implementations out there today. Further = decomposition, however, doesn't really add anything unless it is your = desire to have a network full of extremely intelligent clients that are = always on, and have flat-rate high-speed access to the network = 24x7.

To answer your second question, let's say that's what = we want. On top of all the trouble we have to go through to synchronize = a single presence agent finite state machine with the FSM's of all the = watchers, let's make things that much more interesting, introduce a = plethora of race conditions and error scenarios, and try synchronizing = a fully connected graph of N number of presence agent FSM's to M number = of watchers.

Even if it were possible to sufficiently squash all = of the race conditions and error scenarios, aren't we really pushing it = a little too far to try to do so? Presence and SUBSCRIBE/NOTIFY is = already the near perfect denial-of-service attack due to the messaging = demands it can place on a network. Why inflict N * M number of = messages, when you can do perfectly well, offer more services more = reliably with lower demand on the end user, probably at a cheaper price = (because the terminals don't have to be as fancy, and OA&M = operations are centralized), and have 1 * M number of = messages.


Thoughts?

Brian Stucker
Nortel Networks

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com]

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]

If we leave the stake in the ground that presence = information should not be
aggregated at the watcher, because policy is = difficult at best to apply in
this situation, then we need to ensure one of two = things:

- Making sure that there is one, and only one, PA = (which is what ICQ, AOL,
MSN, etc. have been doing for a long time = now).
[Roy, Radhika R, ALARC]  Are you suggesting = this simplified solution
because, as Paul has pointed out, there is a = fundamental difference the way
forking works in INVITE and SUBSCRIBE/NOTIFY method? = Is this solution due to
the forking problems (not to be satisfactorily = addressed in SUBSCRIBE/NOTIFY
method)?

- Making sure that if there is going to be more than = one PA, either the
results are always aggregated somewhere in the = network (for policy
decisions) or that all of the PA's are kept in sync = (which is extremely
difficult to do).
[Roy, Radhika R, ALARC]  This is what the end = results may look like. I
wonder how can we communicate among multiple PAs to = synchronize states? We
may need to change the forking behavior in = SUBSCRIBE/NOTIFY if the present
suggested method is not satisfactory.

...

------_=_NextPart_001_01C16C86.8744E020-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 18:17:31 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21112 for ; Tue, 13 Nov 2001 18:17:31 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fADNFRCJ017935; Tue, 13 Nov 2001 18:15:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07942; Tue, 13 Nov 2001 18:17:06 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07930 for ; Tue, 13 Nov 2001 18:16:29 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fADNFA123756; Tue, 13 Nov 2001 18:15:10 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD58364 (AUTH pkyzivat); Tue, 13 Nov 2001 18:17:28 -0500 (EST) Message-ID: <3BF1A90C.5D597325@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Stucker , adam.roach@ericsson.com CC: "'Robert Sparks'" , "'James Undery'" , Jonathan Rosenberg , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" Subject: Re: [Simple] 200 vs. 202 References: <933FADF5E673D411B8A30002A5608A0ECA4750@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii 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: Tue, 13 Nov 2001 18:13:16 -0500 Content-Transfer-Encoding: 7bit below... Paul adam.roach@ericsson.com wrote: > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > If dealing with multiple PAs is an obligation of the > > subscribing client, > > then I think that client needs to be given the tools to do it > > right. One > > solution would be to require that if subscribe must be forked, that a > > proxy simply return a 300 with the multiple Contacts rather than > > attempting to do the fork itself. At least then it wouldn't get in the > > way of doing a proper job. > > Forking proxies -- the ones that have already been developed, > sold, delivered, and put in service -- don't know SUBSCRIBE from > INFO, MESSAGE, or FOO. We can't impose ex-post-facto requirements > on them. Yeah, I know that. I should have explained my thinking better. First, most of this discussion has come about because it is more or less impossible to guarantee that two presence agents that appear as forking alternatives are in fact functionally identical. So somebody (I think Jonathan) proposed having the client merge the multiple Notifies that might result from forking a subscribe. My basic conclusion is that forking of subscribe just can't be made to work right as things stand. The proposal to forbid forking in proxies and push it back on the client via a redirect is intended to show one way of making it work. That doesn't make it feasible or practical - the reason you mention is a good argument of why it isn't. But if forking can't work, then we are back to the requirement that there either be only one PA, or else assume that if there are multiple PAs then they are functionally equivalent and know exactly the same state. It is unfortunate that we have no way to verify this, because it will probably be the source of many bugs. So, I believe I am agreeing with Brian. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 13 23:03:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27756 for ; Tue, 13 Nov 2001 23:03:12 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAE40pCJ019054; Tue, 13 Nov 2001 23:00:51 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08809; Tue, 13 Nov 2001 23:01:06 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08798 for ; Tue, 13 Nov 2001 23:00:05 -0500 (EST) Received: from dynamicsoft.com (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fAE3ua602186; Tue, 13 Nov 2001 21:56:36 -0600 Message-ID: <3BF1EB74.7050801@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Sparks CC: "'Roy, Radhika R, ALCTA'" , Sean Olson , "'aki.niemi@nokia.com'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] Expires in MESSAGE References: <9BF66EBF6BEFD942915B4D4D45C051F338E799@DYN-TX-EXCH-001.dynamicsoft.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: Tue, 13 Nov 2001 21:56:36 -0600 Content-Transfer-Encoding: 7bit Do you think the (rather imprecise) definition in bis-05 22.19 is sufficient? Or do we need to add more to the message draft? Robert Sparks wrote: > I'm not sure I understand your point. > > Yes, MESSAGE is a SIP method. > > There are no "same rules" to be considered. The core > spec provides meaning to Expires for REGISTER, and > (somewhat loosely) for INVITE, and those are different! > It has no meaning for the other core methods (Expires > is meaningless for BYE). New methods must specify meaning > (if any) on their own. > > For MESSAGE, I hold that the Expire header contains the > period for which the content of the message should be > considered valid, and it should be up to the applications > involved to decide what to do with expired messages, not > the transport mechanism. Different applications are likely > to need to make different choices. I may have a service where > it is useful for me to know you invited me to lunch, even > though I didn't see your invitation until it was too late to > accept. > > > RjS > > > >>-----Original Message----- >>From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] >>Sent: Monday, November 12, 2001 3:08 PM >>To: Robert Sparks; Sean Olson; 'aki.niemi@nokia.com' >>Cc: simple@mailman.dynamicsoft.com >>Subject: RE: [Simple] Expires in MESSAGE >> >> >>Hi, Roberts: >> >>Is not that "MESSAGE" another method in SIP like INVITEs, >>etc.? If so, why >>do we not use the same rules (e.g., the interpretations can >>be made in the >>SIP layer)? >> >>Radhika >> >>-----Original Message----- >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >>Sent: Monday, November 12, 2001 3:57 PM >>To: Sean Olson; 'aki.niemi@nokia.com' >>Cc: simple@mailman.dynamicsoft.com >>Subject: RE: [Simple] Expires in MESSAGE >> >> >>Interpreting Expires to put bounds on the validity of the content >>of the message is the correct thing to do. >> >>This is, however, information for the applications (or people) using >>the message, not for the routing fabric. In particular, I don't think >>it will make sense to reject "expired" messages at, say, a proxy. >>Even at an endpoint, it should be up the the application running >>above SIP to decide if it wants to process the "expired" message. >>Taking that decision away (by requiring the SIP implementation >>itself to reject the expired message) will do harm. >> >>RjS >> >>-----Original Message----- >>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] >>Sent: Monday, November 12, 2001 1:25 PM >>To: 'aki.niemi@nokia.com' >>Cc: simple@mailman.dynamicsoft.com >>Subject: RE: [Simple] Expires in MESSAGE >> >> >> >>Hi, >> >>I see what you are saying. Should the "Expires: 0" be >>interpreted as in a REGISTER or as in an INVITE? I was >>thinking it would be treated the same as in an INVITE. >>If you receive a MESSAGE with an Expires: that has passed >>(or is literally zero), you return a 400 response and >>"drop" the MESSAGE. >> >>/sean >> >> >>>Hi Sean, >>> >>> >>>>This seems like the most logical interpretation for MESSAGE. >>>>This would also seem to encompass the application you have in >>>>mind below. >>>> >>>I assumed the zero expiry is only defined for REGISTER and >>>SUBSCRIBE, and >>>maybe similar definitions for its semantics for MESSAGE would >>>be needed? >>> >>>Cheers, >>>Aki >>> >>> > _______________________________________________ > 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 Nov 14 02:47:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15667 for ; Wed, 14 Nov 2001 02:47:03 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAE7ilCJ019747; Wed, 14 Nov 2001 02:44:47 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09480; Wed, 14 Nov 2001 02:45:07 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09467 for ; Wed, 14 Nov 2001 02:44:09 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fAE7fpc28711 for ; Wed, 14 Nov 2001 09:41:51 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 14 Nov 2001 09:43:48 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh02nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id WL93PGKD; Wed, 14 Nov 2001 09:43:48 +0200 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id JAA10876; Wed, 14 Nov 2001 09:43:47 +0200 (EET) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id fAE7jiP20824; Wed, 14 Nov 2001 09:45:44 +0200 To: Cc: , Subject: Re: [Simple] Expires in MESSAGE References: <61D824C63B99D311975E00508B0CC98502C66C2C@eamrcnt717.exu.ericsson.se> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <61D824C63B99D311975E00508B0CC98502C66C2C@eamrcnt717.exu.ericsson.se> Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) 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: 14 Nov 2001 09:45:43 +0200 In message <61D824C63B99D311975E00508B0CC98502C66C2C@eamrcnt717.exu.ericsson.se> writes: ... >If want to unregister, I can send a REGISTER with an "Expires" of >"1" and wait a second. I can send a REGISTER with an "Expires" of >"2" and wait two seconds. Or, I can send a REGISTER with an "Expires" >of "0" and wait zero seconds. It all works. Zero isn't a special >case at all. Zero is not magic when handling SIP URLs. However, if you want to (un)register an IM or PRES or TEL URL, not to speak about *, the Expires: 0 suddenly has a special magic meaning. We would like to specify the lifetime of a SIP instant message within a IM gateway. The GSM system allows users to specify how long their SMS messages are valid. If, for instance, an SMS could not have been delivered within 3 hours, it will be dropped. We would like to have similar functionality for SIP IM gateways; sender can select how long her message is kept stored in the IM gateway if it cannot be delivered instantly. If user wants to have truly instant delivery, no store-and-forward in any case, she could use Expires: 0. Pekka _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 14 09:05:07 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23316 for ; Wed, 14 Nov 2001 09:05:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAEE2oCJ020911; Wed, 14 Nov 2001 09:02:50 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10593; Wed, 14 Nov 2001 09:03:07 -0500 (EST) 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 JAA10582 for ; Wed, 14 Nov 2001 09:02:36 -0500 (EST) 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 fAEE0qCJ020899; Wed, 14 Nov 2001 09:00:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 09:02:14 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E7AF@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'Pekka Pessi'" , simple@mailman.dynamicsoft.com Cc: aki.niemi@nokia.com, adam.roach@ericsson.com Subject: RE: [Simple] Expires in MESSAGE 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: Wed, 14 Nov 2001 09:02:11 -0500 And nothing prevents your IM delivery application from interpreting the request this way. Of course, you might run into _really_ bad interactions with the receiver's IM display application when you are capable of delivering the message immediately. "Oh - this one's expired - I won't show it". RjS > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Wednesday, November 14, 2001 1:46 AM > To: simple@mailman.dynamicsoft.com > Cc: aki.niemi@nokia.com; adam.roach@ericsson.com > Subject: Re: [Simple] Expires in MESSAGE > > > In message > <61D824C63B99D311975E00508B0CC98502C66C2C@eamrcnt717.exu.erics > son.se> writes: > ... > >If want to unregister, I can send a REGISTER with an "Expires" of > >"1" and wait a second. I can send a REGISTER with an "Expires" of > >"2" and wait two seconds. Or, I can send a REGISTER with an "Expires" > >of "0" and wait zero seconds. It all works. Zero isn't a special > >case at all. > > Zero is not magic when handling SIP URLs. However, if you want > to (un)register an IM or PRES or TEL URL, not to speak about *, > the Expires: 0 suddenly has a special magic meaning. > > We would like to specify the lifetime of a SIP instant message > within a IM gateway. The GSM system allows users to specify how > long their SMS messages are valid. If, for instance, an SMS > could not have been delivered within 3 hours, it will be > dropped. > > We would like to have similar functionality for SIP IM gateways; > sender can select how long her message is kept stored in the IM > gateway if it cannot be delivered instantly. If user wants to > have truly instant delivery, no store-and-forward in any case, > she could use Expires: 0. > > > Pekka > _______________________________________________ > 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 Nov 14 15:21:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14995 for ; Wed, 14 Nov 2001 15:21:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAEKIYCJ025034; Wed, 14 Nov 2001 15:18:34 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11768; Wed, 14 Nov 2001 15:18:07 -0500 (EST) 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 PAA11756 for ; Wed, 14 Nov 2001 15:17:21 -0500 (EST) 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 fAEKFfCJ025003 for ; Wed, 14 Nov 2001 15:15:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 15:17:01 -0500 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] New I-D on IM transport 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, 14 Nov 2001 15:17:00 -0500 Folks, I've just submitted a new I-D to the archives which proposes a compromise solution for the IM transport in the session model. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom Houri, and myself, in the hopes of making forward progress on this issue. The compromise is to use a protocol called IMTP which is is a subset of SIP, so that it can be forwarded through SIP proxies with proper configuration, but at the same time, only uses reliable transports, and does not use things like forking, record-routing, redirection, and so on. The draft also proposes requirements, which I have gathered from the list discussion. Thanks, 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 Nov 14 15:52:40 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16164 for ; Wed, 14 Nov 2001 15:52:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAEKoGCJ025425; Wed, 14 Nov 2001 15:50:16 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11894; Wed, 14 Nov 2001 15:51:06 -0500 (EST) 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 PAA11883 for ; Wed, 14 Nov 2001 15:50:27 -0500 (EST) 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 fAEKmlCJ025403 for ; Wed, 14 Nov 2001 15:48:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 15:50:08 -0500 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] new I-D on subscribing to buddy lists 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, 14 Nov 2001 15:50:06 -0500 Folks, I just submitted an I-D that talks about subscribing to the entire buddylist. This is a feature common in many systems, and I believe its a key piece of making SIMPLE ideal for wireless. Until the draft appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-rosenberg-simple-buddylist-package-00.tx t Thanks, 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 Nov 14 16:18:26 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16955 for ; Wed, 14 Nov 2001 16:18:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAELFnCJ025699; Wed, 14 Nov 2001 16:15:49 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11991; Wed, 14 Nov 2001 16:16:06 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11980 for ; Wed, 14 Nov 2001 16:15:03 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAELEhP16034 for ; Wed, 14 Nov 2001 15:14:43 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fAELEh711117 for ; Wed, 14 Nov 2001 15:14:43 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Nov 14 15:14:43 2001 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 14 Nov 2001 15:14:43 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'Jonathan Rosenberg'" , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] New I-D on IM transport MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16D51.5C038E40" 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, 14 Nov 2001 15:14:34 -0600 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_01C16D51.5C038E40 Content-Type: text/plain; charset="iso-8859-1" I like the IMTP thing. It would be really really nice if it supported other methods beside MESSAGE. IMTP is basically a very very simple SIP subset so it might be useful in other contexts besides IM. /Sean >-----Original Message----- >From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] >Sent: Wednesday, November 14, 2001 2:17 PM >To: 'simple@mailman.dynamicsoft.com' >Subject: [Simple] New I-D on IM transport > > >Folks, > >I've just submitted a new I-D to the archives which proposes a >compromise >solution for the IM transport in the session model. Until it >appears, you >can pick it up at: > >http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transpo rt-00.txt This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom Houri, and myself, in the hopes of making forward progress on this issue. The compromise is to use a protocol called IMTP which is is a subset of SIP, so that it can be forwarded through SIP proxies with proper configuration, but at the same time, only uses reliable transports, and does not use things like forking, record-routing, redirection, and so on. The draft also proposes requirements, which I have gathered from the list discussion. Thanks, 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_01C16D51.5C038E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New I-D on IM transport

I like the IMTP thing. It would be really = really
nice if it supported other methods beside = MESSAGE.
IMTP is basically a very very simple SIP = subset
so it might be useful in other contexts besides = IM.

/Sean

>-----Original Message-----
>From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>Sent: Wednesday, November 14, 2001 2:17 = PM
>To: 'simple@mailman.dynamicsoft.com'
>Subject: [Simple] New I-D on IM transport
>
>
>Folks,
>
>I've just submitted a new I-D to the archives = which proposes a
>compromise
>solution for the IM transport in the session = model. Until it
>appears, you
>can pick it up at:
>
>http://www.jdrosen.net/papers/draft-rosenberg-simple-i= m-transpo
rt-00.txt

This draft was co-authored by Christian Huitema, = Robert Osborne, Avshalom
Houri, and myself, in the hopes of making forward = progress on this issue.
The compromise is to use a protocol called IMTP = which is is a subset of SIP,
so that it can be forwarded through SIP proxies with = proper configuration,
but at the same time, only uses reliable transports, = and does not use things
like forking, record-routing, redirection, and so = on.

The draft also proposes requirements, which I have = gathered from the list
discussion.

Thanks,
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_01C16D51.5C038E40-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 14 17:43:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20136 for ; Wed, 14 Nov 2001 17:43:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAEMeRCJ026786; Wed, 14 Nov 2001 17:40:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12275; Wed, 14 Nov 2001 17:42:06 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12264 for ; Wed, 14 Nov 2001 17:41:42 -0500 (EST) Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA09017 for ; Wed, 14 Nov 2001 17:41:21 -0500 (EST) Received: (from petkos@localhost) by diamond.cs.columbia.edu (8.10.2+Sun/8.9.3) id fAEMfK701877 for simple@mailman.dynamicsoft.com; Wed, 14 Nov 2001 17:41:20 -0500 (EST) From: "Petri K. Koskelainen" Message-Id: <200111142241.fAEMfK701877@diamond.cs.columbia.edu> To: simple@mailman.dynamicsoft.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Simple] New I-D on IM transport 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, 14 Nov 2001 17:41:20 -0500 (EST) Content-Transfer-Encoding: 7bit Sounds ok. However, couple of comments.. I would add two more requirements: 1: Threading (and sub-threading) e.g. in text chat like of session there may be several topics or threads going-on 2: Message identification (to identify certain message afterwards) Thus, two new IMTP headers would be needed: Message-id and References. This would be similar to NNTP. Also, Subject header is needed (e.g. in chat session it is useful to indicate the thread or topic) Also: "The proxies in this configuration are aware that IMs need to flow through the relays. As a result, they rewrite the SDP in the INVITE and 2xx as it passes through the proxies. The rewrites change the IM session IDs and connection addresses to point to the relays instead" Solution without SDP rewriting in proxies would be preferred.. BR, -- Petri _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 14 18:38:00 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21581 for ; Wed, 14 Nov 2001 18:38:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAENZQCJ027261; Wed, 14 Nov 2001 18:35:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12469; Wed, 14 Nov 2001 18:37:06 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12458 for ; Wed, 14 Nov 2001 18:36:23 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAENZ4T26193; Wed, 14 Nov 2001 18:35:04 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD65073 (AUTH pkyzivat); Wed, 14 Nov 2001 18:37:24 -0500 (EST) Message-ID: <3BF2FF34.F72F124C@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] New I-D on IM transport References: Content-Type: text/plain; charset=us-ascii 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, 14 Nov 2001 18:33:08 -0500 Content-Transfer-Encoding: 7bit I just did a quick scan of this. This seems to balance out some of the conflicting requirements that have been preventing closure on this subject. I will probably have more comments after I think about it a bit, but I see one problem now, with using the comedia draft for connection management. I think you authors see it too, based on comments (from various places) in the text: Streams that use IMTP are always connection oriented, and therefore use the SDP connection oriented media attributes [10] to allow for a single connection to be used for messaging in both directions. ... Need to get the port from somewhere too... maybe just specify a default port for IMTP? May not work with muli- user machines. ... Need a little more rigor in port handling and connection reuse, to ensure that the comedia rules and SIP transport rules are in sync. ... If A wants to send a message to B, it looks for an open TCP connection to 5.6.7.8. If one exists, that is used. If not, one is opened. ... R1 then looks up the request URI, and finds a binding... Since there is an existing TLS connection to that address, this connection is reused: All of these say to me that what you want is not what is described in the comedia draft. That draft: - requires port numbers - assumes that one (or two) connections will be established uniquely for each independently negotiated media stream (is that the right word?). There is no provision for sharing a connection, except for sharing one for the two directions of a single stream. This is clearly not what you want or assume. You would like to use pretty much any connection of the proper type to the corresponding endpoint. This is sufficient because you have the session identifier to demultiplex messages sharing the connection. That is what you need, but it isn't what comedia provides. A related problem is that SDP requires the port number field of the m= line to be a number. You have put the session identifier there, but it isn't strictly numeric. I think SDP is much too rigid about this, but I doubt if we are permitted to change it. You probably need to put the session identifier somewhere else. Rather than attempt to use comedia, I think it would be better to define the IMTP transports so that they make/find connections in the same way that SIP does, but drawing the information to do it from different sources: address from c=, port from m= port field, transport (TCP/TLS) imiplied from m= transport field. Perhaps something like the a=direction field is still needed to force the connection to be opened one way even when traffic will first flow the other way. If so, while similar to comedia it is still a very different way of managing connections. Paul Jonathan Rosenberg wrote: > > Folks, > > I've just submitted a new I-D to the archives which proposes a compromise > solution for the IM transport in the session model. Until it appears, you > can pick it up at: > > http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt > > This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom > Houri, and myself, in the hopes of making forward progress on this issue. > The compromise is to use a protocol called IMTP which is is a subset of SIP, > so that it can be forwarded through SIP proxies with proper configuration, > but at the same time, only uses reliable transports, and does not use things > like forking, record-routing, redirection, and so on. > > The draft also proposes requirements, which I have gathered from the list > discussion. > > Thanks, > 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 Thu Nov 15 08:25:58 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21734 for ; Thu, 15 Nov 2001 08:25:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAFDNUCJ029396; Thu, 15 Nov 2001 08:23:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14963; Thu, 15 Nov 2001 08:25:07 -0500 (EST) Received: from mailrelay.bluelabs.se (mailrelay.bluelabs.se [194.17.38.34]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14950 for ; Thu, 15 Nov 2001 08:24:48 -0500 (EST) From: Hakan.Jonsson@bluelabs.se Received: from blnet-sth-vscan.bluelabs.se (blnet-sth-vscan1.bluelabs.se [194.17.38.247]) by mailrelay.bluelabs.se (Postfix) with SMTP id 78C5517D2 for ; Thu, 15 Nov 2001 14:24:27 +0100 (CET) Received: FROM blue-sth1.bluelabs.se BY blnet-sth-vscan.bluelabs.se ; Thu Nov 15 14:24:27 2001 +0100 Subject: Re: [Simple] new I-D on subscribing to buddy lists To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: X-MIMETrack: Serialize by Router on Blue-sth1/srv/Bluelabs(Release 5.0.6a |January 17, 2001) at 2001-11-15 14:24:27 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id IAA14950 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, 15 Nov 2001 14:24:25 +0100 Content-Transfer-Encoding: 8bit Hi, A few comments on the Buddylist package ID: I agree that it is definitely a needed functionality, especially for wireless applications. From section 2 BLSS Operation: > The BLSS generates an immediate, empty NOTIFY as required by [2], and then obtains the presence state of the users on the buddy list. Does it have done in this order? Is there anything which prevents the BLSS to subscribe to the buddylist users' presence before the user requests the subscription, and send the aggregated state in the first NOTIFY? > As notifications with presence data are received, they can be passed onwards towards the subscriber. Would it be allowable to forward the NOTIFIES from the users subscribed to, to the subscriber as is? Would there be a problem with the subscriber receiving NOTIFIES with an unknown Call-ID? Or could the BLSS reuse the Call-ID from the subscriber? From section 3.5 Notify bodies: > Since the cpim-pidf+xml type contains the identity of the presentity within it, it is clear for which buddy the presence data applies. It would be nice if this draft could describe the behaviour of the BLSS if a presence format used for the body does NOT contain the identity of the presentity, but does instead refer to the presentity in the SIP headers. > The second possibility for aggregation is to use a single body type explicitly designed to support lists of presence data. This format, ????.... Why not use the format proposed to IMPP as specified in the expired draft draft-rosenberg-impp-buddylist-00? /Håkan ======================================= Håkan Jonsson BlueLabs South AB Drottninggatan 18 21189 Malmö Sweden http://www.bluelabs.se _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 15 16:16:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21078 for ; Thu, 15 Nov 2001 16:16:47 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAFLDWCJ003894; Thu, 15 Nov 2001 16:13:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16490; Thu, 15 Nov 2001 16:15:08 -0500 (EST) 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 QAA16476 for ; Thu, 15 Nov 2001 16:14:06 -0500 (EST) 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 PAA24770 for ; Thu, 15 Nov 2001 15:13:45 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 15 Nov 2001 15:09:56 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 15:12:34 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0ED4C579@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] New I-D on IM transport MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16E1A.3D2FEA80" 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, 15 Nov 2001 15:12:31 -0600 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_01C16E1A.3D2FEA80 Content-Type: text/plain; charset="iso-8859-1" Sorry, clicked on wrong thread... Hi Jonathan. As I was skimming through the document, I noticed that you included a requirement for NAT/Firewall traversal, but in the document, the IM transport doesn't really seem to address this very well by including in section 6.2 a firewall setup that basically removes the firewall in the picture for all intents and purposes. I know this is a strawman, so would the intent going forward be to simply have a nailed up TLS connection to clients that have their own firewalls, back to the proxy/relay? The reason I ask is because that would be pretty expensive in terms of network resources to have this connection up all the time for so many endpoints (in an ISP model). Continuing to read... Regards, Brian Stucker -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 14, 2001 2:17 PM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] New I-D on IM transport Folks, I've just submitted a new I-D to the archives which proposes a compromise solution for the IM transport in the session model. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom Houri, and myself, in the hopes of making forward progress on this issue. The compromise is to use a protocol called IMTP which is is a subset of SIP, so that it can be forwarded through SIP proxies with proper configuration, but at the same time, only uses reliable transports, and does not use things like forking, record-routing, redirection, and so on. The draft also proposes requirements, which I have gathered from the list discussion. Thanks, 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_01C16E1A.3D2FEA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New I-D on IM transport

Sorry, clicked on wrong thread...

Hi Jonathan.

As I was skimming through the document, I noticed = that you included a requirement for NAT/Firewall traversal, but in the = document, the IM transport doesn't really seem to address this very = well by including in section 6.2 a firewall setup that basically = removes the firewall in the picture for all intents and = purposes.

I know this is a strawman, so would the intent going = forward be to simply have a nailed up TLS connection to clients that = have their own firewalls, back to the proxy/relay? The reason I ask is = because that would be pretty expensive in terms of network resources to = have this connection up all the time for so many endpoints (in an ISP = model).

Continuing to read...

Regards,

Brian Stucker

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, November 14, 2001 2:17 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] New I-D on IM transport


Folks,

I've just submitted a new I-D to the archives which = proposes a compromise
solution for the IM transport in the session model. = Until it appears, you
can pick it up at:

http://www.jdrosen.net/papers/draft-rosenberg-simple-i= m-transport-00.txt

This draft was co-authored by Christian Huitema, = Robert Osborne, Avshalom
Houri, and myself, in the hopes of making forward = progress on this issue.
The compromise is to use a protocol called IMTP = which is is a subset of SIP,
so that it can be forwarded through SIP proxies with = proper configuration,
but at the same time, only uses reliable transports, = and does not use things
like forking, record-routing, redirection, and so = on.

The draft also proposes requirements, which I have = gathered from the list
discussion.

Thanks,
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_01C16E1A.3D2FEA80-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 15 20:37:05 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01230 for ; Thu, 15 Nov 2001 20:37:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAG1YRCJ005385; Thu, 15 Nov 2001 20:34:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17290; Thu, 15 Nov 2001 20:36:07 -0500 (EST) Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17275 for ; Thu, 15 Nov 2001 20:35:24 -0500 (EST) Received: from wamontgomery ([12.83.72.13]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20011116013502.TIIG4554.mtiwmhc22.worldnet.att.net@wamontgomery> for ; Fri, 16 Nov 2001 01:35:02 +0000 Message-ID: <002b01c16e3f$1fdda920$0e43530c@wamontgomery> From: "warren montgomery" To: References: <200111151700.MAA15613@mailman.dynamicsoft.com> Subject: Re: [Simple] New I-D on IM transport MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, 15 Nov 2001 19:35:27 -0600 Content-Transfer-Encoding: 7bit I've been a lurker on this list for some time and I think the draft is a good compromise on the positions. One thing I observe is that an IMTP session routed throug relays really acts like a circuit -- each message in that session follows the same route through the relays even if there are multiple possibilities (say an enterprise with multiple relay points that could be used). If a relay fails for some reason, the session stops working. This isn't necessarily bad, as it allows IMTP to meet the requirements for sequencing and flow control which could be more difficult, but it may run contrary to user expectation. The session established also winds up being specific to a user's endpiont (i.e. if the user might be available for IM at multiple endpoints, the process of session establishment will presumably pick one for the session, after which moving to a new endpoint means negotiating another session. Again not necessarily bad, but I could see an expectation of being able to migrate from device to device transparently in an IM session like using extension phones. Warren Montgomery wamontgomery@att.net _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 16 10:17:06 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04981 for ; Fri, 16 Nov 2001 10:17:06 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAGFEUCJ007555; Fri, 16 Nov 2001 10:14:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19713; Fri, 16 Nov 2001 10:16:07 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19702 for ; Fri, 16 Nov 2001 10:15:18 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAGFEvT00696; Fri, 16 Nov 2001 10:14:57 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD75893 (AUTH pkyzivat); Fri, 16 Nov 2001 10:16:18 -0500 (EST) Message-ID: <3BF52CBD.88DABE9B@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: warren montgomery CC: simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: <200111151700.MAA15613@mailman.dynamicsoft.com> <002b01c16e3f$1fdda920$0e43530c@wamontgomery> Content-Type: text/plain; charset=us-ascii 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: Fri, 16 Nov 2001 10:11:57 -0500 Content-Transfer-Encoding: 7bit warren montgomery wrote: > > I've been a lurker on this list for some time and I think the draft is a > good compromise on the positions. One thing I observe is that an IMTP > session routed throug relays really acts like a circuit -- each message in > that session follows the same route through the relays even if there are > multiple possibilities (say an enterprise with multiple relay points that > could be used). If a relay fails for some reason, the session stops > working. This isn't necessarily bad, as it allows IMTP to meet the > requirements for sequencing and flow control which could be more difficult, > but it may run contrary to user expectation. > > The session established also winds up being specific to a user's endpiont > (i.e. if the user might be available for IM at multiple endpoints, the > process of session establishment will presumably pick one for the session, > after which moving to a new endpoint means negotiating another session. > Again not necessarily bad, but I could see an expectation of being able to > migrate from device to device transparently in an IM session like using > extension phones. Fundamentally, if you want to move an endpoint in a dialog you need to do a reinvite or a refer, or something like that. It is good that this work the same for IM and for voice. If you want an analogy to extension phones, then of course the solution should resemble that for extension phones. If you want to use SIP, but offer support for extension phones similar to the common experience with analog phones, then you need to do a bunch of work with conferencing models, etc. What you do for phones can then be copied in a very direct way for use with IM. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 16 23:48:39 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05273 for ; Fri, 16 Nov 2001 23:48:38 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH4ijCJ012143; Fri, 16 Nov 2001 23:44:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22757; Fri, 16 Nov 2001 23:46:08 -0500 (EST) 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 XAA22746 for ; Fri, 16 Nov 2001 23:45:58 -0500 (EST) 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 fAH4i9CJ012137; Fri, 16 Nov 2001 23:44:09 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 23:45:32 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , "Roy, Radhika R, ALCTA" , Paul Kyzivat , adam.roach@ericsson.com Cc: Robert Sparks , "'James Undery'" , Jonathan Rosenberg , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" 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: Fri, 16 Nov 2001 23:45:31 -0500 After originally suggesting that we begin thinking about handling merging of presence state at the subscriber, I am now going to back off of that proposal. I fear that the complexities of forking SUBSCRIBE are simply too great compared to the potential benefits, and Brian does a fine job here of providing some good reasons. The simple fact that we have no real way to do authentication (only works if the same number of proxies exists between subscriber and watcher!!) is a clear hint that things are headed in the wrong direction. Forking was meant for the case where you want to reach any one of N things. Thats perfect for INVITE, but clearly it fails for the case where you want to reach all things, as we seem to want here. Effectively, the difference is between designing something that does reliable anycast (which is not too hard) as compared to reliable multicast (which is still largely an unsolved problem in the general case). So, I am proposing we revert to what is currently documented. You accept only the NOTIFY that corresponds to the 2xx to the SUBSCRIBE, and thats it. The recommendation stands to have a PA that aggregates whenever possible. Now, some have pointed out that you cannot avoid forking because of all the deployed proxies that already fork a SUBSCRIBE. However, the networks that these are deployed in do not support presence. I think its reasonable for a network designer that deploys presence to ensure that reasonable things happen; i.e., there is a PA at known aggregation points. Now, if you have users in an existing network that wish to use presence by placing a PA in their clients, well, I would argue that in this case, all bets are off regarding multiple clients. If you want multiple PA for a presentity, you can't really do it unless your SIP provider deploys presence. I think thats a reasonable thing. Let us remember the importance of KISS as a design principle, and not try to solve previously unsolved problems, as Brian points out. Thanks, 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: Tuesday, November 13, 2001 4:03 PM To: Roy, Radhika R, ALCTA; Paul Kyzivat; adam.roach@ericsson.com Cc: 'Robert Sparks'; 'James Undery'; Jonathan Rosenberg; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 Radhika, I am suggesting this simplified approach, and I have done so a number of times before for various reasons. It solves a lot of problems in one fell swoop in my mind, and isn't giving up a whole lot in the process. Arguing the differences in the way forking for INVITE differs from SUBSCRIBE/NOTIFY doesn't seem all that productive to me, because it's comparing apples to oranges, and any solutions suggested by doing so lead to mechanisms that would cause us to have to essentially create SIP/2.1 to handle, or are so awkward that the medicene is arguably worse than the disease. INVITE is not an isomorphic request, and ACK has caused headaches for implementors as well. Ask anyone working on early media what the three-way handshake model that INVITE has done to the complexity of what is otherwise a very straight-forward message sequence. How many drafts are out there because of that little interaction alone? The solution to have one, and only one, PA, is related to the forking problem, yes, but so much more: - Many other implementations that have MILLIONS of subscribers have turned to allowing only 1 PA to solve this problem, is obviously sufficient to meet customer expectations. - Go out and look at the billing models for these IM services that have client-controlled topologies. They can't. If the clients can be their own presence agent, then it makes it next to impossible to charge them for that service. All you can do is charge for connectivity, and that's it. - It's really hard to build presence based services in the network (like network based call screening) unless you provision the client with potentially a great deal of information about the provider network, and expect the customer to leave their device on 24x7. Having more than one presence user agent for a presence agent makes perfect sense. It's a huge advantage that SIMPLE has over the other IM presence implementations out there today. Further decomposition, however, doesn't really add anything unless it is your desire to have a network full of extremely intelligent clients that are always on, and have flat-rate high-speed access to the network 24x7. To answer your second question, let's say that's what we want. On top of all the trouble we have to go through to synchronize a single presence agent finite state machine with the FSM's of all the watchers, let's make things that much more interesting, introduce a plethora of race conditions and error scenarios, and try synchronizing a fully connected graph of N number of presence agent FSM's to M number of watchers. Even if it were possible to sufficiently squash all of the race conditions and error scenarios, aren't we really pushing it a little too far to try to do so? Presence and SUBSCRIBE/NOTIFY is already the near perfect denial-of-service attack due to the messaging demands it can place on a network. Why inflict N * M number of messages, when you can do perfectly well, offer more services more reliably with lower demand on the end user, probably at a cheaper price (because the terminals don't have to be as fancy, and OA&M operations are centralized), and have 1 * M number of messages. Thoughts? Brian Stucker Nortel Networks -----Original Message----- From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] If we leave the stake in the ground that presence information should not be aggregated at the watcher, because policy is difficult at best to apply in this situation, then we need to ensure one of two things: - Making sure that there is one, and only one, PA (which is what ICQ, AOL, MSN, etc. have been doing for a long time now). [Roy, Radhika R, ALARC] Are you suggesting this simplified solution because, as Paul has pointed out, there is a fundamental difference the way forking works in INVITE and SUBSCRIBE/NOTIFY method? Is this solution due to the forking problems (not to be satisfactorily addressed in SUBSCRIBE/NOTIFY method)? - Making sure that if there is going to be more than one PA, either the results are always aggregated somewhere in the network (for policy decisions) or that all of the PA's are kept in sync (which is extremely difficult to do). [Roy, Radhika R, ALARC] This is what the end results may look like. I wonder how can we communicate among multiple PAs to synchronize states? We may need to change the forking behavior in SUBSCRIBE/NOTIFY if the present suggested method is not satisfactory. ... _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 16 23:55:53 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05351 for ; Fri, 16 Nov 2001 23:55:52 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH4rOCJ012220; Fri, 16 Nov 2001 23:53:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22812; Fri, 16 Nov 2001 23:55:07 -0500 (EST) 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 XAA22799 for ; Fri, 16 Nov 2001 23:54:12 -0500 (EST) 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 fAH4qNCJ012213; Fri, 16 Nov 2001 23:52:23 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 23:53:46 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] New I-D on IM transport 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: Fri, 16 Nov 2001 23:53:46 -0500 -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 15, 2001 4:13 PM To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] New I-D on IM transport >Sorry, clicked on wrong thread... >Hi Jonathan. >As I was skimming through the document, I noticed that you included a requirement for >NAT/Firewall traversal, but in the document, the IM transport doesn't really seem to >address this very well by including in section 6.2 a firewall setup that basically removes >the firewall in the picture for all intents and purposes. Huh?? I don't get it. The connection between R1 and R2 would presumably be TLS, and the firewall would have a static rule allowing these two elements to talk to each other over TLS. That addresses the inter-enterprise problem that kicked off much of the discussion on SIP as a transport. >I know this is a strawman, so would the intent going forward be to simply have a nailed up >TLS connection to clients that have their own firewalls, back to the proxy/relay? The >reason I ask is because that would be pretty expensive in terms of network resources to >have this connection up all the time for so many endpoints (in an ISP model). In Figure 2, there is not a tls connection to each client. Perhaps you are talking about some other kind of configuration, for example, a residential one? I.e., Section 2 of draft-rosenberg-sipping-nat-scenarios? In that case, you would presumably use a TURN server to enable this to work. -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: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 14, 2001 2:17 PM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] New I-D on IM transport Folks, I've just submitted a new I-D to the archives which proposes a compromise solution for the IM transport in the session model. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom Houri, and myself, in the hopes of making forward progress on this issue. The compromise is to use a protocol called IMTP which is is a subset of SIP, so that it can be forwarded through SIP proxies with proper configuration, but at the same time, only uses reliable transports, and does not use things like forking, record-routing, redirection, and so on. The draft also proposes requirements, which I have gathered from the list discussion. Thanks, 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 Sat Nov 17 00:00:59 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05385 for ; Sat, 17 Nov 2001 00:00:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH4wPCJ012292; Fri, 16 Nov 2001 23:58:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22852; Sat, 17 Nov 2001 00:00:07 -0500 (EST) 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 XAA22839 for ; Fri, 16 Nov 2001 23:59:54 -0500 (EST) 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 fAH4wACJ012283; Fri, 16 Nov 2001 23:58:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Nov 2001 23:59:33 -0500 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , Jonathan Rosenberg Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] New I-D on IM transport 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: Fri, 16 Nov 2001 23:59:32 -0500 inline. > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Wednesday, November 14, 2001 6:33 PM > To: Jonathan Rosenberg > Cc: 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] New I-D on IM transport > > > I just did a quick scan of this. This seems to balance out some of the > conflicting requirements that have been preventing closure on this > subject. > > I will probably have more comments after I think about it a bit, but I > see one problem now, with using the comedia draft for connection > management. I think you authors see it too, based on comments (from > various places) in the text: > > Streams that use IMTP are always connection oriented, and therefore > use the SDP connection oriented media attributes [10] to > allow for a > single connection to be used for messaging in both directions. > ... > Need to get the port from somewhere too... maybe just > specify a default port for IMTP? May not work with muli- > user machines. > ... > Need a little more rigor in port handling and connection > reuse, to ensure that the comedia rules and SIP transport > rules are in sync. > ... > If A wants to send a message to B, it looks for an open TCP > connection to 5.6.7.8. If one exists, that is used. If not, one is > opened. > ... > R1 then looks up the request URI, and finds a binding... > Since there is an existing TLS > connection to that address, this connection is reused: > > All of these say to me that what you want is not what is described in > the comedia draft. That draft: > > - requires port numbers I think we need that also. > > - assumes that one (or two) connections will be established uniquely > for each independently negotiated media stream (is that the > right word?). There is no provision for sharing a connection, > except for sharing one for the two directions of a single stream. Thats no different that what we have here. There is one connection between a pair of relays, and we want to reuse that for all messaging between the relays. > > This is clearly not what you want or assume. You would like to use > pretty much any connection of the proper type to the corresponding > endpoint. I don't want to establish a new connection if one exists, so there should generally be only one connection to a specific endpoint. > This is sufficient because you have the session > identifier to > demultiplex messages sharing the connection. That is what you > need, but > it isn't what comedia provides. Congestion control would argue for a single connection, though, even though its not needed for demux. > > A related problem is that SDP requires the port number field of the m= > line to be a number. You have put the session identifier there, but it > isn't strictly numeric. I think SDP is much too rigid about > this, but I > doubt if we are permitted to change it. You probably need to put the > session identifier somewhere else. Probably. This was just a strawman, and certainly there are more details to work out. > > Rather than attempt to use comedia, I think it would be > better to define > the IMTP transports so that they make/find connections in the same way > that SIP does, but drawing the information to do it from different > sources: address from c=, port from m= port field, transport (TCP/TLS) > imiplied from m= transport field. Perhaps something like the > a=direction > field is still needed to force the connection to be opened > one way even > when traffic will first flow the other way. If so, while similar to > comedia it is still a very different way of managing connections. I think we definitely want to use the SIP rules for finding connections, and to use the SDP fields as they are defined as much as possible. I'm not convinced that rules out a reference to comedia, but it doesn't matter much. I think we generally agree on what we want to happen, its just a question of the right way to specify it. -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 Sat Nov 17 00:07:26 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05471 for ; Sat, 17 Nov 2001 00:07:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH54hCJ012358; Sat, 17 Nov 2001 00:04:43 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22892; Sat, 17 Nov 2001 00:05:07 -0500 (EST) 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 AAA22879 for ; Sat, 17 Nov 2001 00:04:35 -0500 (EST) 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 fAH52oCJ012347; Sat, 17 Nov 2001 00:02:50 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 17 Nov 2001 00:04:13 -0500 Message-ID: From: Jonathan Rosenberg To: "'warren montgomery'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] New I-D on IM transport 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: Sat, 17 Nov 2001 00:04:13 -0500 > -----Original Message----- > From: warren montgomery [mailto:wamontgomery@worldnet.att.net] > Sent: Thursday, November 15, 2001 8:35 PM > To: simple@mailman.dynamicsoft.com > Subject: Re: [Simple] New I-D on IM transport > > > I've been a lurker on this list for some time and I think the > draft is a > good compromise on the positions. Thanks; I'm glad to have your input. > One thing I observe is that an IMTP > session routed throug relays really acts like a circuit -- > each message in > that session follows the same route through the relays even > if there are > multiple possibilities (say an enterprise with multiple relay > points that > could be used). If a relay fails for some reason, the session stops > working. This isn't necessarily bad, as it allows IMTP to meet the > requirements for sequencing and flow control which could be > more difficult, > but it may run contrary to user expectation. This is no different than record-routing on a dialog. Generally, you need to be careful about what you put into that record-route. You could put a host name in there that resolves via SRV to provide some basic failover and even load balancing capabilities. The same idea would be true here. When an IMTP relay rewrites the SDP, the c line contains a domain name. You could also use an IP address that uses routing tricks to support failover. > > The session established also winds up being specific to a > user's endpiont > (i.e. if the user might be available for IM at multiple endpoints, the > process of session establishment will presumably pick one for > the session, > after which moving to a new endpoint means negotiating > another session. As Paul has pointed out, thats no different than for a voice call, where you would normally use a re-INVITE to update the COntact header. We allow that for this purpose exactly. > Again not necessarily bad, but I could see an expectation of > being able to > migrate from device to device transparently in an IM session > like using > extension phones. Moving amongst extension phones is a park/pickup or transfer kind of function, and should be done the same way for IM as for voice, I would argue. Yet another advantage of the session model.... -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 Sat Nov 17 01:32:09 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09658 for ; Sat, 17 Nov 2001 01:32:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH6SSCJ012502; Sat, 17 Nov 2001 01:28:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23167; Sat, 17 Nov 2001 01:30:08 -0500 (EST) 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 BAA23154 for ; Sat, 17 Nov 2001 01:29:39 -0500 (EST) 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 fAH6RvCJ012496; Sat, 17 Nov 2001 01:27:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 17 Nov 2001 01:29:19 -0500 Message-ID: From: Jonathan Rosenberg To: "'Hakan.Jonsson@bluelabs.se'" , Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] new I-D on subscribing to buddy lists 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: Sat, 17 Nov 2001 01:29:15 -0500 > -----Original Message----- > From: Hakan.Jonsson@bluelabs.se [mailto:Hakan.Jonsson@bluelabs.se] > Sent: Thursday, November 15, 2001 8:24 AM > To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] new I-D on subscribing to buddy lists > > From section 2 BLSS Operation: > > The BLSS generates an immediate, empty NOTIFY as required > by [2], and > then obtains the presence state of the users on the buddy list. > > Does it have done in this order? Nope. > Is there anything which > prevents the BLSS > to subscribe to the buddylist users' presence before the user > requests the > subscription, and send the aggregated state in the first NOTIFY? Nothing prevents that, no. > > > As notifications with presence data are received, they can be passed > onwards towards the subscriber. > > Would it be allowable to forward the NOTIFIES from the users > subscribed to, > to the subscriber as is? Would there be a problem with the subscriber > receiving NOTIFIES with an unknown Call-ID? Or could the BLSS > reuse the > Call-ID from the subscriber? I think they should be converted. You'll also run into sequence numbering issues too. The content (the bodies) can simply be copied. > > From section 3.5 Notify bodies: > > Since the cpim-pidf+xml type contains the identity of the presentity > within it, it is clear for which buddy the presence data applies. > > It would be nice if this draft could describe the behaviour > of the BLSS if > a presence format used for the body does NOT contain the > identity of the > presentity, but does instead refer to the presentity in the > SIP headers. The point is that this function is not needed, and arguably doesn't belong in the headers, as its a characteristic of the thing being subscribed to, which is the buddy list itself. > > > The second possibility for aggregation is to use a single body type > explicitly designed to support lists of presence data. This format, > ????.... > > Why not use the format proposed to IMPP as specified in the > expired draft > draft-rosenberg-impp-buddylist-00? That is the wrong thing. draft-rosenberg-impp-buddylist is merely a list of buddies (effectively, the thing I subscribe to); it is not a way to represent their presence states. -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 Sat Nov 17 01:37:10 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10343 for ; Sat, 17 Nov 2001 01:37:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH6XQCJ012555; Sat, 17 Nov 2001 01:33:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23207; Sat, 17 Nov 2001 01:35:08 -0500 (EST) 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 BAA23194 for ; Sat, 17 Nov 2001 01:34:18 -0500 (EST) 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 fAH6WZCJ012551; Sat, 17 Nov 2001 01:32:35 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 17 Nov 2001 01:33:56 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Robert Sparks Cc: "'Roy, Radhika R, ALCTA'" , Sean Olson , "'aki.niemi@nokia.com'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Expires in MESSAGE 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: Sat, 17 Nov 2001 01:33:54 -0500 I think the MESSAGE draft requires additional wording. Most of the semantics for zero expirations is now in the section on registrations, where it belongs. We need a similar kind of thing for IM. -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: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, November 13, 2001 10:57 PM > To: Robert Sparks > Cc: 'Roy, Radhika R, ALCTA'; Sean Olson; 'aki.niemi@nokia.com'; > simple@mailman.dynamicsoft.com > Subject: Re: [Simple] Expires in MESSAGE > > > Do you think the (rather imprecise) definition in bis-05 22.19 is > sufficient? Or do we need to add more to the message draft? > > Robert Sparks wrote: > > > I'm not sure I understand your point. > > > > Yes, MESSAGE is a SIP method. > > > > There are no "same rules" to be considered. The core > > spec provides meaning to Expires for REGISTER, and > > (somewhat loosely) for INVITE, and those are different! > > It has no meaning for the other core methods (Expires > > is meaningless for BYE). New methods must specify meaning > > (if any) on their own. > > > > For MESSAGE, I hold that the Expire header contains the > > period for which the content of the message should be > > considered valid, and it should be up to the applications > > involved to decide what to do with expired messages, not > > the transport mechanism. Different applications are likely > > to need to make different choices. I may have a service where > > it is useful for me to know you invited me to lunch, even > > though I didn't see your invitation until it was too late to > > accept. > > > > > > RjS > > > > > > > >>-----Original Message----- > >>From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > >>Sent: Monday, November 12, 2001 3:08 PM > >>To: Robert Sparks; Sean Olson; 'aki.niemi@nokia.com' > >>Cc: simple@mailman.dynamicsoft.com > >>Subject: RE: [Simple] Expires in MESSAGE > >> > >> > >>Hi, Roberts: > >> > >>Is not that "MESSAGE" another method in SIP like INVITEs, > >>etc.? If so, why > >>do we not use the same rules (e.g., the interpretations can > >>be made in the > >>SIP layer)? > >> > >>Radhika > >> > >>-----Original Message----- > >>From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > >>Sent: Monday, November 12, 2001 3:57 PM > >>To: Sean Olson; 'aki.niemi@nokia.com' > >>Cc: simple@mailman.dynamicsoft.com > >>Subject: RE: [Simple] Expires in MESSAGE > >> > >> > >>Interpreting Expires to put bounds on the validity of the content > >>of the message is the correct thing to do. > >> > >>This is, however, information for the applications (or people) using > >>the message, not for the routing fabric. In particular, I > don't think > >>it will make sense to reject "expired" messages at, say, a proxy. > >>Even at an endpoint, it should be up the the application running > >>above SIP to decide if it wants to process the "expired" message. > >>Taking that decision away (by requiring the SIP implementation > >>itself to reject the expired message) will do harm. > >> > >>RjS > >> > >>-----Original Message----- > >>From: Sean Olson (EUS) [mailto:sean.olson@ericsson.com] > >>Sent: Monday, November 12, 2001 1:25 PM > >>To: 'aki.niemi@nokia.com' > >>Cc: simple@mailman.dynamicsoft.com > >>Subject: RE: [Simple] Expires in MESSAGE > >> > >> > >> > >>Hi, > >> > >>I see what you are saying. Should the "Expires: 0" be > >>interpreted as in a REGISTER or as in an INVITE? I was > >>thinking it would be treated the same as in an INVITE. > >>If you receive a MESSAGE with an Expires: that has passed > >>(or is literally zero), you return a 400 response and > >>"drop" the MESSAGE. > >> > >>/sean > >> > >> > >>>Hi Sean, > >>> > >>> > >>>>This seems like the most logical interpretation for MESSAGE. > >>>>This would also seem to encompass the application you have in > >>>>mind below. > >>>> > >>>I assumed the zero expiry is only defined for REGISTER and > >>>SUBSCRIBE, and > >>>maybe similar definitions for its semantics for MESSAGE would > >>>be needed? > >>> > >>>Cheers, > >>>Aki > >>> > >>> > > _______________________________________________ > > 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 Sat Nov 17 01:38:59 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10629 for ; Sat, 17 Nov 2001 01:38:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAH6ZPCJ012632; Sat, 17 Nov 2001 01:35:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23257; Sat, 17 Nov 2001 01:37:07 -0500 (EST) 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 BAA23246 for ; Sat, 17 Nov 2001 01:36:46 -0500 (EST) 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 fAH6Z3CJ012628; Sat, 17 Nov 2001 01:35:03 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 17 Nov 2001 01:36:24 -0500 Message-ID: From: Jonathan Rosenberg To: Robert Sparks , "'Pekka Pessi'" , simple@mailman.dynamicsoft.com Cc: aki.niemi@nokia.com, adam.roach@ericsson.com Subject: RE: [Simple] Expires in MESSAGE 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: Sat, 17 Nov 2001 01:36:23 -0500 > -----Original Message----- > From: Robert Sparks [mailto:rsparks@dynamicsoft.com] > Sent: Wednesday, November 14, 2001 9:02 AM > To: 'Pekka Pessi'; simple@mailman.dynamicsoft.com > Cc: aki.niemi@nokia.com; adam.roach@ericsson.com > Subject: RE: [Simple] Expires in MESSAGE > > > And nothing prevents your IM delivery application > from interpreting the request this way. Of course, > you might run into _really_ bad interactions with > the receiver's IM display application when you are > capable of delivering the message immediately. "Oh - > this one's expired - I won't show it". To be more preceise, the interpretation at a gateway which would allow it to be dropped after the expiration is a valid interpretation. But, that is not to say that the meaning is "this is how long a gateway will retry it for". Should a client believe that this is the interpretation, and therefore set Expires:0, it may very well be ignored at the terminating host. Expires is as it says, it is the lifetime over which this message is useful. After that time has expired, the message is no longer useful. That applies to all systems, not just gateways. -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 Sat Nov 17 14:38:29 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29060 for ; Sat, 17 Nov 2001 14:38:29 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAHJXVCJ013750; Sat, 17 Nov 2001 14:33:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25840; Sat, 17 Nov 2001 14:35:10 -0500 (EST) 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 OAA25826 for ; Sat, 17 Nov 2001 14:34:04 -0500 (EST) 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 NAA19937 for ; Sat, 17 Nov 2001 13:33:44 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Sat, 17 Nov 2001 13:26:55 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 17 Nov 2001 13:32:48 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0ED9AB11@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] New I-D on IM transport MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C16F9E.A262E2B0" 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: Sat, 17 Nov 2001 13:32:46 -0600 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_01C16F9E.A262E2B0 Content-Type: text/plain; charset="iso-8859-1" Yes, I'm referring to the residential case. Sorry, should have been more direct. Brian -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, November 16, 2001 10:54 PM To: Stucker, Brian [NGB:B635:EXCH]; Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] New I-D on IM transport -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Thursday, November 15, 2001 4:13 PM To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' Subject: RE: [Simple] New I-D on IM transport >Sorry, clicked on wrong thread... >Hi Jonathan. >As I was skimming through the document, I noticed that you included a requirement for >NAT/Firewall traversal, but in the document, the IM transport doesn't really seem to >address this very well by including in section 6.2 a firewall setup that basically removes >the firewall in the picture for all intents and purposes. Huh?? I don't get it. The connection between R1 and R2 would presumably be TLS, and the firewall would have a static rule allowing these two elements to talk to each other over TLS. That addresses the inter-enterprise problem that kicked off much of the discussion on SIP as a transport. >I know this is a strawman, so would the intent going forward be to simply have a nailed up >TLS connection to clients that have their own firewalls, back to the proxy/relay? The >reason I ask is because that would be pretty expensive in terms of network resources to >have this connection up all the time for so many endpoints (in an ISP model). In Figure 2, there is not a tls connection to each client. Perhaps you are talking about some other kind of configuration, for example, a residential one? I.e., Section 2 of draft-rosenberg-sipping-nat-scenarios? In that case, you would presumably use a TURN server to enable this to work. -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: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, November 14, 2001 2:17 PM To: 'simple@mailman.dynamicsoft.com' Subject: [Simple] New I-D on IM transport Folks, I've just submitted a new I-D to the archives which proposes a compromise solution for the IM transport in the session model. Until it appears, you can pick it up at: http://www.jdrosen.net/papers/draft-rosenberg-simple-im-transport-00.txt This draft was co-authored by Christian Huitema, Robert Osborne, Avshalom Houri, and myself, in the hopes of making forward progress on this issue. The compromise is to use a protocol called IMTP which is is a subset of SIP, so that it can be forwarded through SIP proxies with proper configuration, but at the same time, only uses reliable transports, and does not use things like forking, record-routing, redirection, and so on. The draft also proposes requirements, which I have gathered from the list discussion. Thanks, 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_01C16F9E.A262E2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] New I-D on IM transport

Yes, I'm referring to the residential case. Sorry, = should have been more direct.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, November 16, 2001 10:54 PM
To: Stucker, Brian [NGB:B635:EXCH]; Jonathan = Rosenberg;
'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] New I-D on IM transport




 
-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Thursday, November 15, 2001 4:13 PM
To: Jonathan Rosenberg; = 'simple@mailman.dynamicsoft.com'
Subject: RE: [Simple] New I-D on IM transport


>Sorry, clicked on wrong thread...
>Hi Jonathan.
>As I was skimming through the document, I = noticed that you included a
requirement for
>NAT/Firewall traversal, but in the document, the = IM transport doesn't
really seem to
>address this very well by including in section = 6.2 a firewall setup that
basically removes
>the firewall in the picture for all intents and = purposes.

Huh?? I don't get it. The connection between R1 and = R2 would presumably be
TLS, and the firewall would have a static rule = allowing these two elements
to talk to each other over TLS. That addresses the = inter-enterprise problem
that kicked off much of the discussion on SIP as a = transport.

>I know this is a strawman, so would the intent = going forward be to simply
have a nailed up
>TLS connection to clients that have their own = firewalls, back to the
proxy/relay? The
>reason I ask is because that would be pretty = expensive in terms of network
resources to
>have this connection up all the time for so many = endpoints (in an ISP
model).

In Figure 2, there is not a tls connection to each = client. Perhaps you are
talking about some other kind of configuration, for = example, a residential
one? I.e., Section 2 of = draft-rosenberg-sipping-nat-scenarios? In that case,
you would presumably use a TURN server to enable = this to work.

-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: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, November 14, 2001 2:17 PM
To: 'simple@mailman.dynamicsoft.com'
Subject: [Simple] New I-D on IM transport


Folks,
I've just submitted a new I-D to the archives which = proposes a compromise
solution for the IM transport in the session model. = Until it appears, you
can pick it up at:
http://www.jdrosen.net/papers/draft-rosenberg-simple-i= m-transport-00.txt
This draft was co-authored by Christian Huitema, = Robert Osborne, Avshalom
Houri, and myself, in the hopes of making forward = progress on this issue.
The compromise is to use a protocol called IMTP = which is is a subset of SIP,

so that it can be forwarded through SIP proxies with = proper configuration,
but at the same time, only uses reliable transports, = and does not use things

like forking, record-routing, redirection, and so on. =
The draft also proposes requirements, which I have = gathered from the list
discussion.
Thanks,
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_01C16F9E.A262E2B0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 19 10:36:19 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04626 for ; Mon, 19 Nov 2001 10:36:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAJFVZhp001688; Mon, 19 Nov 2001 10:31:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01331; Mon, 19 Nov 2001 10:33:10 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01319 for ; Mon, 19 Nov 2001 10:32:40 -0500 (EST) Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fAJFWF414154 for ; Mon, 19 Nov 2001 10:32:16 -0500 (EST) Received: from att.com ([135.210.75.193]) by maillennium.att.com (labmail) with SMTP id <20011119153215099001qjdpe> (Authid: tony@maillennium.att.com); Mon, 19 Nov 2001 15:32:15 +0000 Message-ID: <3BF925DE.C710F50@att.com> From: Tony Hansen X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: Content-Type: text/plain; charset=us-ascii 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: Mon, 19 Nov 2001 10:31:42 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > -----Original Message----- > > From: warren montgomery [mailto:wamontgomery@worldnet.att.net] > > ... > > Again not necessarily bad, but I could see an expectation of > > being able to > > migrate from device to device transparently in an IM session > > like using > > extension phones. > > Moving amongst extension phones is a park/pickup or transfer kind of > function, and should be done the same way for IM as for voice, I would > argue. Yet another advantage of the session model.... Yes indeed. Anything that can be done with one should be doable with the other. (This may be a tautology:) And the more we make the models comparable, the more easily it will be to do those things in similar ways. Tony Hansen tony@att.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 19 11:14:58 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07170 for ; Mon, 19 Nov 2001 11:14:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAJGAQhp002046; Mon, 19 Nov 2001 11:10:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01469; Mon, 19 Nov 2001 11:12:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01458 for ; Mon, 19 Nov 2001 11:11:59 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAJG6CP09429; Mon, 19 Nov 2001 10:06:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAJG6B521902; Mon, 19 Nov 2001 10:06:11 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id KAA22324; Mon, 19 Nov 2001 10:06:11 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , "'Brian Stucker'" , "Roy, Radhika R, ALCTA" , "Paul Kyzivat" , Cc: "Robert Sparks" , "'James Undery'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C4E@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: 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, 19 Nov 2001 10:06:08 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Forking was meant for the case where you > want to reach any > one of N things. Thats perfect for INVITE, but clearly it > fails for the case > where you want to reach all things, as we seem to want here. This is a very concise restatement of the primary argument that I made when I proposed that we deprecate forking for all non-INVITE requests. SIP, as a working group, rejected this exact argument then (over my objections). I fail to see why the situation would change now. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 19 17:18:55 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29723 for ; Mon, 19 Nov 2001 17:18:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAJMGRhp005590; Mon, 19 Nov 2001 17:16:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02657; Mon, 19 Nov 2001 17:18:07 -0500 (EST) 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 RAA02646 for ; Mon, 19 Nov 2001 17:17:39 -0500 (EST) 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 fAJMEehp005559; Mon, 19 Nov 2001 17:14:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 17:16:03 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , Jonathan Rosenberg , "'Brian Stucker'" , "Roy, Radhika R, ALCTA" , Paul Kyzivat Cc: Robert Sparks , "'James Undery'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" 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: Mon, 19 Nov 2001 17:16:02 -0500 > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, November 19, 2001 11:06 AM > To: 'Jonathan Rosenberg'; 'Brian Stucker'; Roy, Radhika R, ALCTA; Paul > Kyzivat; adam.roach@ericsson.com > Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai > (c)'; 'Brazier Lachlan'; 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Forking was meant for the case where you > > want to reach any > > one of N things. Thats perfect for INVITE, but clearly it > > fails for the case > > where you want to reach all things, as we seem to want here. > > This is a very concise restatement of the primary argument > that I made when I proposed that we deprecate forking for > all non-INVITE requests. Forking works fine if you want to reach any one of N things, but thats not what is desired here. I don't think we should deprecate forking for non-INVITE, I am merely saying that we specify that the presence event package stay as defined, and pretty much assume no forking. If it does happen, you get no gaurantees on getting full state of the presenttiy. -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 Mon Nov 19 17:53:57 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01845 for ; Mon, 19 Nov 2001 17:53:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAJMpOhp005879; Mon, 19 Nov 2001 17:51:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02789; Mon, 19 Nov 2001 17:53:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02778 for ; Mon, 19 Nov 2001 17:52:40 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAJMgaP20952; Mon, 19 Nov 2001 16:42:36 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAJMgaC25336; Mon, 19 Nov 2001 16:42:36 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id QAA26266; Mon, 19 Nov 2001 16:42:34 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , , "'Brian Stucker'" , "Roy, Radhika R, ALCTA" , "Paul Kyzivat" Cc: "Robert Sparks" , "'James Undery'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C5C@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: 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, 19 Nov 2001 16:42:33 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Forking works fine if you want to reach any one of N things, > but thats not what is desired here. I don't think we should > deprecate forking for non-INVITE... Your arguments aren't internally consistent. (a) INVITE is the only request for which the response is allowed to take an arbitrarily long period of time. All other requests must receive a response pretty much immediately. (b) Many Non-INVITE requests cannot be cancelled. Even if they can be cancelled, CANCELs will usually fail (arrive too late) because of (a). (c) Because of both (a) and (b), any forked non-INVITE request has an extremely high chance of succeeding at all reached endpoints. (d) Because of (c), any forked non-INVITE request acts as a "reach all of" request instead of a "reach any of" request. (e) By (d), your asserting that forking of non-INVITEs is okay necessarily means that you are accepting a "reach all of" semantic for forking -- but you already asserted that this is a Really Bad Thing. Given the forgoing arguments, I believe we have precisely three solutions to this problem: 1. (Makes the assumption that "reach all of" is invalid) We can "outlaw" valid forking for SUBSCRIBE (although your proposal was to outlaw forking for presence, your arguments were based on outlawing forking for SUBSCRIBE in general), and use the specific mechanism of sending a 481 to certain NOTIFYs to tear down the dialog. Then you can solve the problem of the "reach all of" semantics in a method-specific way for MESSAGE. After that, you can solve the problem in a message specific way for INFO. Then, a new mechanism for REFER. And something else for UPLOAD. Something different for FOO. And so on. 2. (Makes the assumption that "reach all of" in invalid) A more coherent approach would be to outlaw forking for all non-INVITEs. 3. (Makes the assumption that "reach all of" is valid) I believe that the easiest and fastest way forward would be to *allow* forking of arbitrary requests with "reach all of" semantics, and attempt to solve the concrete problem(s), once they are proposed, that arise from allowing multiple dialogs to be established by a SUBSCRIBE in the context of presence. I'll go for options 2 and 3. Option 1 is pure and unbridled insanity. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 19 20:59:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05480 for ; Mon, 19 Nov 2001 20:58:41 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAK08Php006473; Mon, 19 Nov 2001 19:08:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03097; Mon, 19 Nov 2001 19:10:08 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03084 for ; Mon, 19 Nov 2001 19:09:50 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAK04JP14936; Mon, 19 Nov 2001 18:04:19 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAK04IC20768; Mon, 19 Nov 2001 18:04:18 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id SAA03372; Mon, 19 Nov 2001 18:04:18 -0600 (CST) Reply-To: To: "'Brian Stucker'" , "adam.roach" , "'Jonathan Rosenberg'" , "Roy, Radhika R, ALCTA" , "Paul Kyzivat" Cc: "Robert Sparks" , "'James Undery'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C5E@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <933FADF5E673D411B8A30002A5608A0EE0FE06@zrc2c012.us.nortel.com> 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, 19 Nov 2001 18:04:16 -0600 Content-Transfer-Encoding: 7bit Part 2... note that I'm addressing multiple presence sources specifically here, **not** the general SUB/NOT forking problem (that was my previous mail). Perhaps I'm being daft, but I can't see what is so complicated about merging state received from two different sources, GIVEN THE WAY THE CPIM PRESENCE FORMAT IS DEFINED. I've put those nine words in all-caps because they are crucial to understanding what I'm trying to say. For presence, the state information delivered by a concentration point in the network will contain the state of several different entities. This differs in no real way (in terms of forming a single coherent state to be rendered to the user) from the situation in which you receive this state directly from each entity. I've given it a bit of thought, and (for presence, at least), can really see only two open issues if we allow multiple PUAs to be established by an initial SUBSCRIBE: - How do we ensure that the presentity ID is unique? (We could fix this by requiring GUIDs or similar), and - How do we make sure that we don't get information about a particular presentity from more than one source (e.g. an endpoint PUA and a concentrator) -- or, if you do (and they are in conflict), how do you sort out which is authoritative? The answer to this isn't as trivial, but I can think of several easy-to-implement schemes that would make this work out just fine. Neither of these are showstoppers. The first one isn't even difficult. That said, there have been several intelligent people on this list insisting that there are hordes of intractable problems that prohibit merging state at the subscriber end, so I must be overlooking something massive. It would be instructive -- and probably more conducive to progress -- if people would argue their points in specific terms (such as detailing individual problems, like the two I describe above) instead of just calling the entire problem set "difficult" and throwing their hands up. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Monday, November 19, 2001 5:35 PM To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 Adam, I respect your viewpoint and the work in the event draft, but I'm going to have to disagree with you. Option 1 makes the assumption that sometimes reach-all is valid, and sometimes it's not. It's flexible. If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481. Option 2 is overkill. It might not matter to the particular service or mechanism being deployed if the forking behavior of non-INVITE messages is going to pose a problem. Not allowing forking would be (to me) like forcing everything to use TCP instead of UDP. Plus, it's SIP/2.1. Option 3 assumes that the problem of having multiple dialogs created as part of presence is a good thing to have in the first place. And it's SIP/2.1. My argument all along has been that even if the forking issues are resolved, there's fundamental problems with allowing multiple subscriptions to be created, in the case of presence. That because of this, for presence, it is best to very strongly recommend that only one presence agent be in the network at any point at time. It would not matter if forking worked exactly how everyone wanted it to work or not, you'd still have serious problems. Option 1 works for presence as far as I can see, and does not place or pose any restrictions on others who, for their event package, want to loosen up the rules a bit more. It is a client problem entirely. The network won't even know what is going on or care. Am I missing something? Regards, Brian Stucker _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 19 20:59:04 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05618 for ; Mon, 19 Nov 2001 20:59:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAJNwPhp006369; Mon, 19 Nov 2001 18:58:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03042; Mon, 19 Nov 2001 19:00:08 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03026 for ; Mon, 19 Nov 2001 18:58:50 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fAJNqST21194; Mon, 19 Nov 2001 17:52:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAJNqSE09199; Mon, 19 Nov 2001 17:52:28 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id RAA02373; Mon, 19 Nov 2001 17:52:27 -0600 (CST) Reply-To: To: "'Brian Stucker'" , "adam.roach" , "'Jonathan Rosenberg'" , "Roy, Radhika R, ALCTA" , "Paul Kyzivat" Cc: "Robert Sparks" , "'James Undery'" , "'Moran Tim \(NET/Dallas\)'" , "'Ngo, Dai \(c\)'" , "'Brazier Lachlan'" , "'simple'" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C5D@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <933FADF5E673D411B8A30002A5608A0EE0FE06@zrc2c012.us.nortel.com> 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, 19 Nov 2001 17:52:25 -0600 Content-Transfer-Encoding: 7bit I think what you interpreted option 1 to mean is what I was proposing by option 3. That is: forking of SUBSCRIBE is allowed in general, but that subscribers always have the option to terminate unwanted subscriptions with a 481. I suspect that the reason you misinterpreted what I said is that you didn't frame it in the correct context. I quote Jonathan Rosenberg's comments below; it is to them that I am responding: "I fear that the complexities of forking SUBSCRIBE are simply too great compared to the potential benefits, and Brian does a fine job here of providing some good reasons. The simple fact that we have no real way to do authentication (only works if the same number of proxies exists between subscriber and watcher!!) is a clear hint that things are headed in the wrong direction. Forking was meant for the case where you want to reach any one of N things. Thats perfect for INVITE, but clearly it fails for the case where you want to reach all things, as we seem to want here. Effectively, the difference is between designing something that does reliable anycast (which is not too hard) as compared to reliable multicast (which is still largely an unsolved problem in the general case)." There are individual points in there to which I could respond (i.e. we're not solving reliable multicasting in the general case), but the thrust of his arguments don't address the presence case -- his arguments claim that valid forking of SUBSCRIBE is always bad, in all contexts, no matter what, game over. Instead, I agree with you (on this particular point): "If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481." This, as I understand it, is the agreement we nailed down about 8 months ago. I can't stop us from revisiting the issue, but I'm growing increasingly frustrated that the very same people who claim to be in a hurry insist an repeatedly opening the same can of worms over and over and over again. In this message, I've done nothing but agree with you. To avoid mixing the discussions, I'll be sending out a note in which I disagree with you about presence in particular in just a moment. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Monday, November 19, 2001 5:35 PM To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 Adam, I respect your viewpoint and the work in the event draft, but I'm going to have to disagree with you. Option 1 makes the assumption that sometimes reach-all is valid, and sometimes it's not. It's flexible. If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481. Option 2 is overkill. It might not matter to the particular service or mechanism being deployed if the forking behavior of non-INVITE messages is going to pose a problem. Not allowing forking would be (to me) like forcing everything to use TCP instead of UDP. Plus, it's SIP/2.1. Option 3 assumes that the problem of having multiple dialogs created as part of presence is a good thing to have in the first place. And it's SIP/2.1. My argument all along has been that even if the forking issues are resolved, there's fundamental problems with allowing multiple subscriptions to be created, in the case of presence. That because of this, for presence, it is best to very strongly recommend that only one presence agent be in the network at any point at time. It would not matter if forking worked exactly how everyone wanted it to work or not, you'd still have serious problems. Option 1 works for presence as far as I can see, and does not place or pose any restrictions on others who, for their event package, want to loosen up the rules a bit more. It is a client problem entirely. The network won't even know what is going on or care. Am I missing something? Regards, Brian Stucker _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 19 20:59:05 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05635 for ; Mon, 19 Nov 2001 20:59:04 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAJNaPhp006206; Mon, 19 Nov 2001 18:36:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02946; Mon, 19 Nov 2001 18:38:07 -0500 (EST) 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 SAA02935 for ; Mon, 19 Nov 2001 18:37:10 -0500 (EST) 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 RAA11198 for ; Mon, 19 Nov 2001 17:36:48 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 19 Nov 2001 17:29:34 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 17:35:27 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE0FE06@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , "'Jonathan Rosenberg'" , "Roy, Radhika R, ALCTA" , Paul Kyzivat Cc: Robert Sparks , "'James Undery'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'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_01C17152.D9839220" 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: Mon, 19 Nov 2001 17:35:19 -0600 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_01C17152.D9839220 Content-Type: text/plain; charset="iso-8859-1" Adam, I respect your viewpoint and the work in the event draft, but I'm going to have to disagree with you. Option 1 makes the assumption that sometimes reach-all is valid, and sometimes it's not. It's flexible. If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481. Option 2 is overkill. It might not matter to the particular service or mechanism being deployed if the forking behavior of non-INVITE messages is going to pose a problem. Not allowing forking would be (to me) like forcing everything to use TCP instead of UDP. Plus, it's SIP/2.1. Option 3 assumes that the problem of having multiple dialogs created as part of presence is a good thing to have in the first place. And it's SIP/2.1. My argument all along has been that even if the forking issues are resolved, there's fundamental problems with allowing multiple subscriptions to be created, in the case of presence. That because of this, for presence, it is best to very strongly recommend that only one presence agent be in the network at any point at time. It would not matter if forking worked exactly how everyone wanted it to work or not, you'd still have serious problems. Option 1 works for presence as far as I can see, and does not place or pose any restrictions on others who, for their event package, want to loosen up the rules a bit more. It is a client problem entirely. The network won't even know what is going on or care. Am I missing something? Regards, Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, November 19, 2001 4:43 PM To: 'Jonathan Rosenberg'; adam.roach; Stucker, Brian [NGB:B635:EXCH]; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Forking works fine if you want to reach any one of N things, > but thats not what is desired here. I don't think we should > deprecate forking for non-INVITE... Your arguments aren't internally consistent. (a) INVITE is the only request for which the response is allowed to take an arbitrarily long period of time. All other requests must receive a response pretty much immediately. (b) Many Non-INVITE requests cannot be cancelled. Even if they can be cancelled, CANCELs will usually fail (arrive too late) because of (a). (c) Because of both (a) and (b), any forked non-INVITE request has an extremely high chance of succeeding at all reached endpoints. (d) Because of (c), any forked non-INVITE request acts as a "reach all of" request instead of a "reach any of" request. (e) By (d), your asserting that forking of non-INVITEs is okay necessarily means that you are accepting a "reach all of" semantic for forking -- but you already asserted that this is a Really Bad Thing. Given the forgoing arguments, I believe we have precisely three solutions to this problem: 1. (Makes the assumption that "reach all of" is invalid) We can "outlaw" valid forking for SUBSCRIBE (although your proposal was to outlaw forking for presence, your arguments were based on outlawing forking for SUBSCRIBE in general), and use the specific mechanism of sending a 481 to certain NOTIFYs to tear down the dialog. Then you can solve the problem of the "reach all of" semantics in a method-specific way for MESSAGE. After that, you can solve the problem in a message specific way for INFO. Then, a new mechanism for REFER. And something else for UPLOAD. Something different for FOO. And so on. 2. (Makes the assumption that "reach all of" in invalid) A more coherent approach would be to outlaw forking for all non-INVITEs. 3. (Makes the assumption that "reach all of" is valid) I believe that the easiest and fastest way forward would be to *allow* forking of arbitrary requests with "reach all of" semantics, and attempt to solve the concrete problem(s), once they are proposed, that arise from allowing multiple dialogs to be established by a SUBSCRIBE in the context of presence. I'll go for options 2 and 3. Option 1 is pure and unbridled insanity. /a ------_=_NextPart_001_01C17152.D9839220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

Adam,

I respect your viewpoint and the work in the event = draft, but I'm going to have to disagree with you.

Option 1 makes the assumption that sometimes = reach-all is valid, and sometimes it's not. It's flexible. If you want = to pay attention to an apparently unsolicited NOTIFY that matches = everything except the TO tag from the 200 OK from the SUBSCRIBE, go for = it. If not, then you've got a problem, squelch the messages you don't = want with the 481.

Option 2 is overkill. It might not matter to the = particular service or mechanism being deployed if the forking behavior = of non-INVITE messages is going to pose a problem. Not allowing forking = would be (to me) like forcing everything to use TCP instead of UDP. = Plus, it's SIP/2.1.

Option 3 assumes that the problem of having multiple = dialogs created as part of presence is a good thing to have in the = first place. And it's SIP/2.1.

My argument all along has been that even if the = forking issues are resolved, there's fundamental problems with allowing = multiple subscriptions to be created, in the case of presence. That = because of this, for presence, it is best to very strongly recommend = that only one presence agent be in the network at any point at time. It = would not matter if forking worked exactly how everyone wanted it to = work or not, you'd still have serious problems.

Option 1 works for presence as far as I can see, and = does not place or pose any restrictions on others who, for their event = package, want to loosen up the rules a bit more. It is a client problem = entirely. The network won't even know what is going on or = care.

Am I missing something?

Regards,

Brian Stucker



-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, November 19, 2001 4:43 PM
To: 'Jonathan Rosenberg'; adam.roach; Stucker, Brian = [NGB:B635:EXCH];
Roy, Radhika R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim = (NET/Dallas)'; 'Ngo, Dai
(c)'; 'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
>
> Forking works fine if you want to reach any one = of N things,
> but thats not what is desired here. I don't = think we should
> deprecate forking for non-INVITE...

Your arguments aren't internally consistent.

(a) INVITE is the only request for which the response = is allowed to
    take an arbitrarily long period = of time. All other requests must
    receive a response pretty much = immediately.

(b) Many Non-INVITE requests cannot be cancelled. = Even if they can be
    cancelled, CANCELs will usually = fail (arrive too late) because of (a).

(c) Because of both (a) and (b), any forked = non-INVITE request has an
    extremely high chance of = succeeding at all reached endpoints.

(d) Because of (c), any forked non-INVITE request = acts as a "reach all
    of" request instead of a = "reach any of" request.

(e) By (d), your asserting that forking of = non-INVITEs is okay necessarily
    means that you are accepting a = "reach all of" semantic for forking --
    but you already asserted that = this is a Really Bad Thing.

Given the forgoing arguments, I believe we have = precisely three solutions
to this problem:

1. (Makes the assumption that "reach all = of" is invalid)
   We can "outlaw" valid forking = for SUBSCRIBE (although your proposal was
   to outlaw forking for presence, your = arguments were based on outlawing
   forking for SUBSCRIBE in general), and = use the specific mechanism of
   sending a 481 to certain NOTIFYs to = tear down the dialog. Then you can
   solve the problem of the "reach = all of" semantics in a method-specific
   way for MESSAGE. After that, you can = solve the problem in a message
   specific way for INFO. Then, a new = mechanism for REFER. And something
   else for UPLOAD. Something different = for FOO. And so on.

2. (Makes the assumption that "reach all = of" in invalid)
   A more coherent approach would be to = outlaw forking for all non-INVITEs.

3. (Makes the assumption that "reach all = of" is valid)
   I believe that the easiest and fastest = way forward would be to *allow*
   forking of arbitrary requests with = "reach all of" semantics, and attempt
   to solve the concrete problem(s), once = they are proposed, that arise
   from allowing multiple dialogs to be = established by a SUBSCRIBE in the
   context of presence.

I'll go for options 2 and 3. Option 1 is pure and = unbridled insanity.

/a

------_=_NextPart_001_01C17152.D9839220-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 00:17:05 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13931 for ; Tue, 20 Nov 2001 00:17:05 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAK5Eahp007371; Tue, 20 Nov 2001 00:14:36 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04030; Tue, 20 Nov 2001 00:16:19 -0500 (EST) 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 AAA04019 for ; Tue, 20 Nov 2001 00:15:53 -0500 (EST) 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 fAK5CWhp007366; Tue, 20 Nov 2001 00:12:32 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 00:13:56 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , Jonathan Rosenberg , "'Brian Stucker'" , "Roy, Radhika R, ALCTA" , Paul Kyzivat Cc: Robert Sparks , "'James Undery'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" 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, 20 Nov 2001 00:13:55 -0500 > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, November 19, 2001 5:43 PM > To: 'Jonathan Rosenberg'; adam.roach@ericsson.com; 'Brian > Stucker'; Roy, > Radhika R, ALCTA; Paul Kyzivat > Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai > (c)'; 'Brazier Lachlan'; 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Forking works fine if you want to reach any one of N things, > > but thats not what is desired here. I don't think we should > > deprecate forking for non-INVITE... > > Your arguments aren't internally consistent. I never make any guarantees about the internal consistency of my arguments over time ;) > > (a) INVITE is the only request for which the response is allowed to > take an arbitrarily long period of time. All other requests must > receive a response pretty much immediately. > > (b) Many Non-INVITE requests cannot be cancelled. Even if they can be > cancelled, CANCELs will usually fail (arrive too late) > because of (a). > > (c) Because of both (a) and (b), any forked non-INVITE request has an > extremely high chance of succeeding at all reached endpoints. > > (d) Because of (c), any forked non-INVITE request acts as a "reach all > of" request instead of a "reach any of" request. I think you are misunderstanding what I meant by "reach all". Of course it will reach all endpoints for the reasons you describe above. By "reach all", I meant that each of the things I could contact is different in some way, so that I need to have a dialog set up with all of them in order for things to properly work. In other words, "reach all" would mean that the presence state of the presentity is distributed, in a non-overlapping way, across N PUA, and I need to get presence data from all of them for me to get a correct view of the presentity state. By reach any, it means that the request hits all N endpoints, but that I only need to talk to one of them in the end to get the information I want. My apologies for a poor choice of terms. > > (e) By (d), your asserting that forking of non-INVITEs is > okay necessarily > means that you are accepting a "reach all of" semantic > for forking -- > but you already asserted that this is a Really Bad Thing. > > Given the forgoing arguments, I believe we have precisely > three solutions > to this problem: > > 1. (Makes the assumption that "reach all of" is invalid) > We can "outlaw" valid forking for SUBSCRIBE (although your > proposal was > to outlaw forking for presence, your arguments were based > on outlawing > forking for SUBSCRIBE in general), and use the specific > mechanism of > sending a 481 to certain NOTIFYs to tear down the dialog. > Then you can > solve the problem of the "reach all of" semantics in a > method-specific > way for MESSAGE. After that, you can solve the problem in a message > specific way for INFO. Then, a new mechanism for REFER. > And something > else for UPLOAD. Something different for FOO. And so on. I'm certainly not proposing that. I was merely arguing that it was simpler to assume that a presentity is represented by one PA (with that PA perhaps composing presence data from multiple sources), so that the SUBSCRIBE can fork, but that you would 481 all NOTIFY except the one matching the 2xx. Adam later writes: > There are individual points in there to which I could respond > (i.e. we're not solving reliable multicasting in the general case), > but the thrust of his arguments don't address the presence > case -- his arguments claim that valid forking of SUBSCRIBE is > always bad, in all contexts, no matter what, game over. No; hopefully my above statements clarify. > > Instead, I agree with you (on this particular point): "If you > want to pay attention to an apparently unsolicited NOTIFY that > matches everything except the TO tag from the 200 OK from the > SUBSCRIBE, go for it. If not, then you've got a problem, squelch > the messages you don't want with the 481." To which I agree as well. > This, as I understand it, is the agreement we nailed down about > 8 months ago. I can't stop us from revisiting the issue, but I'm > growing increasingly frustrated that the very same people who > claim to be in a hurry insist an repeatedly opening the same can > of worms over and over and over again. I can only assume you refer to me here; I am not advocating overturning that decision, I am merely advocating we keep what is already documented in the presence spec, and what has been there since the draft was written, which is that you 481 all NOTIFY except the one that matches the 2xx to SUBSCRIBE. -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 Tue Nov 20 00:27:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14173 for ; Tue, 20 Nov 2001 00:27:51 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAK5PNhp007436; Tue, 20 Nov 2001 00:25:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04091; Tue, 20 Nov 2001 00:27:07 -0500 (EST) 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 AAA04080 for ; Tue, 20 Nov 2001 00:26:09 -0500 (EST) 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 fAK5NVhp007427; Tue, 20 Nov 2001 00:23:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 00:24:56 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , "'Brian Stucker'" , Jonathan Rosenberg , "Roy, Radhika R, ALCTA" , Paul Kyzivat Cc: Robert Sparks , "'James Undery'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" 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, 20 Nov 2001 00:24:54 -0500 > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, November 19, 2001 7:04 PM > To: 'Brian Stucker'; adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, > ALCTA; Paul Kyzivat > Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai > (c)'; 'Brazier Lachlan'; 'simple' > Subject: RE: [Simple] 200 vs. 202 > > > Part 2... note that I'm addressing multiple presence sources > specifically here, **not** the general SUB/NOT forking problem > (that was my previous mail). > > Perhaps I'm being daft, but I can't see what is so complicated > about merging state received from two different sources, > GIVEN THE WAY THE CPIM PRESENCE FORMAT IS DEFINED. The problem is not that it cannot be done, the problem is that it cannot be done within the policy constraints of the PA. Creating an aggregate presence document is more than just a union operation, its also a filtering operation which removes/modifies depending on lots of things. That kind of processing can only rationally happen at a PA in the presentity's domain. This is why we have 481'd extra NOTIFY's from the very beginning - we are trying to keep the composition function in the presentity domain. > I've given it a bit of thought, and (for presence, at least), can > really see only two open issues if we allow multiple PUAs to be > established by an initial SUBSCRIBE: > > - How do we ensure that the presentity ID is unique? (We could fix > this by requiring GUIDs or similar), and > > - How do we make sure that we don't get information about a particular > presentity from more than one source (e.g. an endpoint PUA and a > concentrator) -- or, if you do (and they are in conflict), how do > you sort out which is authoritative? The answer to this > isn't as trivial, > but I can think of several easy-to-implement schemes that would make > this work out just fine. > > Neither of these are showstoppers. The first one isn't even difficult. Agreed. I don't see these as a real problem. > > That said, there have been several intelligent people on this list > insisting that there are hordes of intractable problems that prohibit > merging state at the subscriber end, so I must be overlooking > something > massive. It would be instructive -- and probably more conducive to > progress -- if people would argue their points in specific terms (such > as detailing individual problems, like the two I describe > above) instead > of just calling the entire problem set "difficult" and throwing their > hands up. Well, beyond the one above, which is very much presence specific, Robert raised some issues that I had not thought of which were not specific to presence: http://mailman.dynamicsoft.com/pipermail/simple/2001-November/001052.html I am not sure the DoS one was ever resolved; it may not be a big issue. The one about authentication requiring the same number of proxies seemed a serious one, with no clear solution. James had proposed something: http://mailman.dynamicsoft.com/pipermail/simple/2001-November/001070.html but it had many issues, as he himself indicated. At this point in time, I am really eager to just keep things simple, and not worry about problems that we don't need to. It is much easier, IMHO, to simply assume that the client does not need to do aggregation, than to assume it may need to. Since we have no clear requirement or need to solve this broader problem, why bother? -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 Tue Nov 20 09:37:46 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11282 for ; Tue, 20 Nov 2001 09:37:45 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKEVRhp008778; Tue, 20 Nov 2001 09:31:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05745; Tue, 20 Nov 2001 09:33:09 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05734 for ; Tue, 20 Nov 2001 09:32:30 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAKEW9T06903; Tue, 20 Nov 2001 09:32:09 -0500 (EST) Received: from cisco.com (rtp-vpn1-73.cisco.com [10.82.224.73]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD89954 (AUTH pkyzivat); Tue, 20 Nov 2001 09:33:29 -0500 (EST) Message-ID: <3BFA68B2.94C6CEB2@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'warren montgomery'" , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: Content-Type: text/plain; charset=us-ascii 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: Tue, 20 Nov 2001 09:29:06 -0500 Content-Transfer-Encoding: 7bit Jonathan - I agreed with most of what you said in this reply, but there was one point I take issue with: Jonathan Rosenberg wrote: [snip] > When an IMTP relay rewrites the SDP, the c line contains a domain name. The latest versions of SDP don't permit FQDNs in the c= line. I never did hear why this change was made. While it often may be wise to avoid FQDNs in sdp, it seems pretty heavy handed to forbid them, since as you point out here there may be cases where they are useful. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 10:09:29 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13285 for ; Tue, 20 Nov 2001 10:09:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKF6Uhp009165; Tue, 20 Nov 2001 10:06:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05872; Tue, 20 Nov 2001 10:08:07 -0500 (EST) 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 KAA05861 for ; Tue, 20 Nov 2001 10:07:15 -0500 (EST) 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 JAA21807 for ; Tue, 20 Nov 2001 09:06:52 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 20 Nov 2001 08:59:35 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 09:05:26 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE1006A@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , "adam.roach" , "'Jonathan Rosenberg'" , "Roy, Radhika R, ALCTA" , Paul Kyzivat Cc: "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'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_01C171D4.C4304DF0" 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: Tue, 20 Nov 2001 09:05:18 -0600 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_01C171D4.C4304DF0 Content-Type: text/plain; charset="iso-8859-1" I think that'll work just fine, and it's what you have in your draft, isn't it? I wasn't as involved with the list 8 months ago, so if I'm included in the people who are opening up old issues, apologies for that. Regards, Brian -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, November 19, 2001 5:52 PM To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 I think what you interpreted option 1 to mean is what I was proposing by option 3. That is: forking of SUBSCRIBE is allowed in general, but that subscribers always have the option to terminate unwanted subscriptions with a 481. I suspect that the reason you misinterpreted what I said is that you didn't frame it in the correct context. I quote Jonathan Rosenberg's comments below; it is to them that I am responding: "I fear that the complexities of forking SUBSCRIBE are simply too great compared to the potential benefits, and Brian does a fine job here of providing some good reasons. The simple fact that we have no real way to do authentication (only works if the same number of proxies exists between subscriber and watcher!!) is a clear hint that things are headed in the wrong direction. Forking was meant for the case where you want to reach any one of N things. Thats perfect for INVITE, but clearly it fails for the case where you want to reach all things, as we seem to want here. Effectively, the difference is between designing something that does reliable anycast (which is not too hard) as compared to reliable multicast (which is still largely an unsolved problem in the general case)." There are individual points in there to which I could respond (i.e. we're not solving reliable multicasting in the general case), but the thrust of his arguments don't address the presence case -- his arguments claim that valid forking of SUBSCRIBE is always bad, in all contexts, no matter what, game over. Instead, I agree with you (on this particular point): "If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481." This, as I understand it, is the agreement we nailed down about 8 months ago. I can't stop us from revisiting the issue, but I'm growing increasingly frustrated that the very same people who claim to be in a hurry insist an repeatedly opening the same can of worms over and over and over again. In this message, I've done nothing but agree with you. To avoid mixing the discussions, I'll be sending out a note in which I disagree with you about presence in particular in just a moment. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Monday, November 19, 2001 5:35 PM To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 Adam, I respect your viewpoint and the work in the event draft, but I'm going to have to disagree with you. Option 1 makes the assumption that sometimes reach-all is valid, and sometimes it's not. It's flexible. If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481. Option 2 is overkill. It might not matter to the particular service or mechanism being deployed if the forking behavior of non-INVITE messages is going to pose a problem. Not allowing forking would be (to me) like forcing everything to use TCP instead of UDP. Plus, it's SIP/2.1. Option 3 assumes that the problem of having multiple dialogs created as part of presence is a good thing to have in the first place. And it's SIP/2.1. My argument all along has been that even if the forking issues are resolved, there's fundamental problems with allowing multiple subscriptions to be created, in the case of presence. That because of this, for presence, it is best to very strongly recommend that only one presence agent be in the network at any point at time. It would not matter if forking worked exactly how everyone wanted it to work or not, you'd still have serious problems. Option 1 works for presence as far as I can see, and does not place or pose any restrictions on others who, for their event package, want to loosen up the rules a bit more. It is a client problem entirely. The network won't even know what is going on or care. Am I missing something? Regards, Brian Stucker ------_=_NextPart_001_01C171D4.C4304DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

I think that'll work just fine, and it's what you = have in your draft, isn't it? I wasn't as involved with the list 8 = months ago, so if I'm included in the people who are opening up old = issues, apologies for that.

Regards,

Brian

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, November 19, 2001 5:52 PM
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; = 'Jonathan Rosenberg';
Roy, Radhika R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim = (NET/Dallas)'; 'Ngo, Dai
(c)'; 'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202


I think what you interpreted option 1 to mean is what = I
was proposing by option 3. That is: forking of = SUBSCRIBE
is allowed in general, but that subscribers always = have
the option to terminate unwanted subscriptions with = a
481.

I suspect that the reason you misinterpreted what I = said
is that you didn't frame it in the correct context. = I quote
Jonathan Rosenberg's comments below; it is to them = that
I am responding:

    "I fear that the complexities = of forking SUBSCRIBE are
     simply too great compared = to the potential benefits, and
     Brian does a fine job here = of providing some good reasons.
     The simple fact that we = have no real way to do
     authentication (only works = if the same number of proxies
     exists between subscriber = and watcher!!) is a clear hint
     that things are headed in = the wrong direction. Forking was
     meant for the case where = you want to reach any one of N
     things. Thats perfect for = INVITE, but clearly it fails
     for the case where you want = to reach all things, as we
     seem to want here. = Effectively, the difference is between
     designing something that = does reliable anycast (which is
     not too hard) as compared = to reliable multicast (which is
     still largely an unsolved = problem in the general case)."

There are individual points in there to which I could = respond
(i.e. we're not solving reliable multicasting in the = general case),
but the thrust of his arguments don't address the = presence
case -- his arguments claim that valid forking of = SUBSCRIBE is
always bad, in all contexts, no matter what, game = over.

Instead, I agree with you (on this particular point): = "If you
want to pay attention to an apparently unsolicited = NOTIFY that
matches everything except the TO tag from the 200 OK = from the
SUBSCRIBE, go for it. If not, then you've got a = problem, squelch
the messages you don't want with the = 481."

This, as I understand it, is the agreement we nailed = down about
8 months ago. I can't stop us from revisiting the = issue, but I'm
growing increasingly frustrated that the very same = people who
claim to be in a hurry insist an repeatedly opening = the same can
of worms over and over and over again.

In this message, I've done nothing but agree with = you. To avoid
mixing the discussions, I'll be sending out a note = in which I
disagree with you about presence in particular in = just a moment.

/a

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Monday, November 19, 2001 5:35 PM
To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika = R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim = (NET/Dallas)'; 'Ngo, Dai (c)';
'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202


Adam,
I respect your viewpoint and the work in the event = draft, but I'm going to have
to disagree with you.
Option 1 makes the assumption that sometimes = reach-all is valid, and sometimes
it's not. It's flexible. If you want to pay = attention to an apparently
unsolicited NOTIFY that matches everything except = the TO tag from the 200 OK
from the SUBSCRIBE, go for it. If not, then you've = got a problem, squelch the
messages you don't want with the 481.
Option 2 is overkill. It might not matter to the = particular service or
mechanism being deployed if the forking behavior of = non-INVITE messages is
going to pose a problem. Not allowing forking would = be (to me) like forcing
everything to use TCP instead of UDP. Plus, it's = SIP/2.1.
Option 3 assumes that the problem of having multiple = dialogs created as part of
presence is a good thing to have in the first place. = And it's SIP/2.1.
My argument all along has been that even if the = forking issues are resolved,
there's fundamental problems with allowing multiple = subscriptions to be
created, in the case of presence. That because of = this, for presence, it is
best to very strongly recommend that only one = presence agent be in the network
at any point at time. It would not matter if forking = worked exactly how
everyone wanted it to work or not, you'd still have = serious problems.
Option 1 works for presence as far as I can see, and = does not place or pose any
restrictions on others who, for their event package, = want to loosen up the
rules a bit more. It is a client problem entirely. = The network won't even know
what is going on or care.
Am I missing something?
Regards,
Brian Stucker

------_=_NextPart_001_01C171D4.C4304DF0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 10:11:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13477 for ; Tue, 20 Nov 2001 10:11:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKF9Nhp009253; Tue, 20 Nov 2001 10:09:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05905; Tue, 20 Nov 2001 10:11:07 -0500 (EST) Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05893 for ; Tue, 20 Nov 2001 10:10:14 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA02087; Tue, 20 Nov 2001 10:09:51 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ASZ03908; Tue, 20 Nov 2001 10:10:00 -0500 (EST) Message-Id: <4.3.2.7.2.20011120100643.00b2cf58@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] 200 vs. 202 Cc: "'adam.roach@ericsson.com'" , "'Brian Stucker'" , Jonathan Rosenberg , "Roy, Radhika R, ALCTA" , Paul Kyzivat , Robert Sparks , "'James Undery'" , "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'simple'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 20 Nov 2001 10:15:07 -0500 Jonathan and others, I have seen in this latest thread a lot of "assumptions" regarding "reach any" and "reach all" that seem to have an effect on how the involved nodes operate. May I suggest that if a proxy decides to change a "reach one" request into something else, that it should also indicate that in the message itself. Then at least the nodes attempting to "aggregate" or "choose best" or "handle one response" would be more clue-full. It might also be useful for the node that creates the forking problem to make sure it is in the return path and take responsibility for handling the responses. But, perhaps that is too much to hope for (too constraining). Mike At 12:24 AM 11/20/2001 -0500, Jonathan Rosenberg wrote: > > > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Monday, November 19, 2001 7:04 PM > > To: 'Brian Stucker'; adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, > > ALCTA; Paul Kyzivat > > Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai > > (c)'; 'Brazier Lachlan'; 'simple' > > Subject: RE: [Simple] 200 vs. 202 > > > > > > Part 2... note that I'm addressing multiple presence sources > > specifically here, **not** the general SUB/NOT forking problem > > (that was my previous mail). > > > > Perhaps I'm being daft, but I can't see what is so complicated > > about merging state received from two different sources, > > GIVEN THE WAY THE CPIM PRESENCE FORMAT IS DEFINED. > >The problem is not that it cannot be done, the problem is that it cannot be >done within the policy constraints of the PA. Creating an aggregate presence >document is more than just a union operation, its also a filtering operation >which removes/modifies depending on lots of things. That kind of processing >can only rationally happen at a PA in the presentity's domain. This is why >we have 481'd extra NOTIFY's from the very beginning - we are trying to keep >the composition function in the presentity domain. > > > I've given it a bit of thought, and (for presence, at least), can > > really see only two open issues if we allow multiple PUAs to be > > established by an initial SUBSCRIBE: > > > > - How do we ensure that the presentity ID is unique? (We could fix > > this by requiring GUIDs or similar), and > > > > - How do we make sure that we don't get information about a particular > > presentity from more than one source (e.g. an endpoint PUA and a > > concentrator) -- or, if you do (and they are in conflict), how do > > you sort out which is authoritative? The answer to this > > isn't as trivial, > > but I can think of several easy-to-implement schemes that would make > > this work out just fine. > > > > Neither of these are showstoppers. The first one isn't even difficult. > >Agreed. I don't see these as a real problem. > > > > > That said, there have been several intelligent people on this list > > insisting that there are hordes of intractable problems that prohibit > > merging state at the subscriber end, so I must be overlooking > > something > > massive. It would be instructive -- and probably more conducive to > > progress -- if people would argue their points in specific terms (such > > as detailing individual problems, like the two I describe > > above) instead > > of just calling the entire problem set "difficult" and throwing their > > hands up. > >Well, beyond the one above, which is very much presence specific, Robert >raised some issues that I had not thought of which were not specific to >presence: > >http://mailman.dynamicsoft.com/pipermail/simple/2001-November/001052.html > >I am not sure the DoS one was ever resolved; it may not be a big issue. The >one about authentication requiring the same number of proxies seemed a >serious one, with no clear solution. James had proposed something: > >http://mailman.dynamicsoft.com/pipermail/simple/2001-November/001070.html > >but it had many issues, as he himself indicated. > >At this point in time, I am really eager to just keep things simple, and not >worry about problems that we don't need to. It is much easier, IMHO, to >simply assume that the client does not need to do aggregation, than to >assume it may need to. Since we have no clear requirement or need to solve >this broader problem, why bother? > >-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 Tue Nov 20 10:29:33 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14736 for ; Tue, 20 Nov 2001 10:29:32 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKFQThp009500; Tue, 20 Nov 2001 10:26:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05997; Tue, 20 Nov 2001 10:28:07 -0500 (EST) 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 KAA05986 for ; Tue, 20 Nov 2001 10:27:51 -0500 (EST) 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 JAA28388 for ; Tue, 20 Nov 2001 09:27:29 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 20 Nov 2001 09:23:19 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 09:26:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE100D1@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , "adam.roach" , "'Jonathan Rosenberg'" , "Roy, Radhika R, ALCTA" , Paul Kyzivat Cc: "'Moran Tim (NET/Dallas)'" , "'Ngo, Dai (c)'" , "'Brazier Lachlan'" , "'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_01C171D7.AB0EDD70" 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, 20 Nov 2001 09:26:04 -0600 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_01C171D7.AB0EDD70 Content-Type: text/plain; charset="iso-8859-1" There are two major problems, as I see it, and some other, minor problems (two of which you've pointed out). I think I've outlined these before, but I'll do so again. Jonathan has pointed out probably the biggest problem of all, the matter of applying policy. It needs to be at a location that the watcher does not have any control over, or visibility into otherwise the value of changing presence information based on policy is really lost. This requires someone, somewhere in the picture, who is not the watcher, to apply policy, and do so in a consistient manner. This means that at the very least, a PA or PAs somewhere have to apply policy. Which leads me to my next major problem... All of presence can be viewed as nothing more than synchronizing two finite state machines. Very straightforward. Anything that has a definite set of states can be viewed this way. In order to apply policy at several PAs prior to having them send their revised presence document to the watcher, all of the PAs version of what the policy should be needs to be synchronized. That means that they all need to have a way of keeping them synchronized, and SUB/NOT is a mechanism for doing so. In order to ensure that all of the presentity's presence documents (revised or otherwise) makes it to the watcher in a consistient manner, the PAs also have to watch each other's presence as well. Synchronizing 2 state machines is pretty easy, which is what a single SUB/NOT dialogue sets up. Synchronizing N state machines is very tough. With two FSM's, synchronization is done in a uni-directional, lock-step manner. With N FSM's synchronization is done in a multi-way manner. This is much more difficult: - Glare: You run into problems where you get two different states for the same resource at a given PA, and must figure out which one is the correct one to take. Simply taking the first one, or the last one isn't good enough. Since we have no common clocking source, there's no way of knowing which one is the correct presence tuple to use. The closest solution to this is to count how many hops each presence tuple has taken, and always take the one closest to the source. However, since we're not guaranteed to be able to even contact all of the PAs at any given time, this may wind up being problematic. You may be stuck using presence tuple data that has traveled over several hops, getting kludged up along the way. - Race Conditions: Two or more given presence tuples change, but the changes have only propagated half-way through the set of presence agents. Since any change should trigger a notification, the watcher will see presence tuple states "flutter" all over before (hopefully) settling down to the correct state. If the PAs are all watching one another, and the watcher is watching all of the PAs, then it should always (in theory) settle on the correct state, but could be in incorrect intermediate states for a noticible period of time. - Complete Knowledge of State: In a 2 FSM synchronization scenario, knowing the complete state picture is simple. You are given it by the master FSM, and you're done. In the N-way FSM synch scenario, you have to know the state of N FSM's. However, we do not have a reliable mechanism for ensuring that this happens (thus the thread on forking began once again). I could go into more detail on some of the other problems, but this is a good start in my view. As Jonathan points out, who is screaming for there to be multiple PAs in the first place? We can obviously do very well with a single presence agent because this is how every major *widely deployed* presence model works, and people don't seem to mind at all. Regards, Brian Stucker Nortel Networks -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, November 19, 2001 6:04 PM To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 Part 2... note that I'm addressing multiple presence sources specifically here, **not** the general SUB/NOT forking problem (that was my previous mail). Perhaps I'm being daft, but I can't see what is so complicated about merging state received from two different sources, GIVEN THE WAY THE CPIM PRESENCE FORMAT IS DEFINED. I've put those nine words in all-caps because they are crucial to understanding what I'm trying to say. For presence, the state information delivered by a concentration point in the network will contain the state of several different entities. This differs in no real way (in terms of forming a single coherent state to be rendered to the user) from the situation in which you receive this state directly from each entity. I've given it a bit of thought, and (for presence, at least), can really see only two open issues if we allow multiple PUAs to be established by an initial SUBSCRIBE: - How do we ensure that the presentity ID is unique? (We could fix this by requiring GUIDs or similar), and - How do we make sure that we don't get information about a particular presentity from more than one source (e.g. an endpoint PUA and a concentrator) -- or, if you do (and they are in conflict), how do you sort out which is authoritative? The answer to this isn't as trivial, but I can think of several easy-to-implement schemes that would make this work out just fine. Neither of these are showstoppers. The first one isn't even difficult. That said, there have been several intelligent people on this list insisting that there are hordes of intractable problems that prohibit merging state at the subscriber end, so I must be overlooking something massive. It would be instructive -- and probably more conducive to progress -- if people would argue their points in specific terms (such as detailing individual problems, like the two I describe above) instead of just calling the entire problem set "difficult" and throwing their hands up. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Monday, November 19, 2001 5:35 PM To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika R, ALCTA; Paul Kyzivat Cc: Robert Sparks; 'James Undery'; 'Moran Tim (NET/Dallas)'; 'Ngo, Dai (c)'; 'Brazier Lachlan'; 'simple' Subject: RE: [Simple] 200 vs. 202 Adam, I respect your viewpoint and the work in the event draft, but I'm going to have to disagree with you. Option 1 makes the assumption that sometimes reach-all is valid, and sometimes it's not. It's flexible. If you want to pay attention to an apparently unsolicited NOTIFY that matches everything except the TO tag from the 200 OK from the SUBSCRIBE, go for it. If not, then you've got a problem, squelch the messages you don't want with the 481. Option 2 is overkill. It might not matter to the particular service or mechanism being deployed if the forking behavior of non-INVITE messages is going to pose a problem. Not allowing forking would be (to me) like forcing everything to use TCP instead of UDP. Plus, it's SIP/2.1. Option 3 assumes that the problem of having multiple dialogs created as part of presence is a good thing to have in the first place. And it's SIP/2.1. My argument all along has been that even if the forking issues are resolved, there's fundamental problems with allowing multiple subscriptions to be created, in the case of presence. That because of this, for presence, it is best to very strongly recommend that only one presence agent be in the network at any point at time. It would not matter if forking worked exactly how everyone wanted it to work or not, you'd still have serious problems. Option 1 works for presence as far as I can see, and does not place or pose any restrictions on others who, for their event package, want to loosen up the rules a bit more. It is a client problem entirely. The network won't even know what is going on or care. Am I missing something? Regards, Brian Stucker ------_=_NextPart_001_01C171D7.AB0EDD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

There are two major problems, as I see it, and some = other, minor problems (two of which you've pointed out). I think I've = outlined these before, but I'll do so again.

Jonathan has pointed out probably the biggest problem = of all, the matter of applying policy. It needs to be at a location = that the watcher does not have any control over, or visibility into = otherwise the value of changing presence information based on policy is = really lost. This requires someone, somewhere in the picture, who is = not the watcher, to apply policy, and do so in a consistient manner. = This means that at the very least, a PA or PAs somewhere have to apply = policy. Which leads me to my next major problem...

All of presence can be viewed as nothing more than = synchronizing two finite state machines. Very straightforward. Anything = that has a definite set of states can be viewed this way. In order to = apply policy at several PAs prior to having them send their revised = presence document to the watcher, all of the PAs version of what the = policy should be needs to be synchronized. That means that they all = need to have a way of keeping them synchronized, and SUB/NOT is a = mechanism for doing so. In order to ensure that all of the presentity's = presence documents (revised or otherwise) makes it to the watcher in a = consistient manner, the PAs also have to watch each other's presence as = well. Synchronizing 2 state machines is pretty easy, which is what a = single SUB/NOT dialogue sets up. Synchronizing N state machines is very = tough. With two FSM's, synchronization is done in a uni-directional, = lock-step manner. With N FSM's synchronization is done in a multi-way = manner. This is much more difficult:

- Glare: You run into problems where you get two = different states for the same resource at a given PA, and must figure = out which one is the correct one to take. Simply taking the first one, = or the last one isn't good enough. Since we have no common clocking = source, there's no way of knowing which one is the correct presence = tuple to use. The closest solution to this is to count how many hops = each presence tuple has taken, and always take the one closest to the = source. However, since we're not guaranteed to be able to even contact = all of the PAs at any given time, this may wind up being problematic. = You may be stuck using presence tuple data that has traveled over = several hops, getting kludged up along the way.

- Race Conditions: Two or more given presence tuples = change, but the changes have only propagated half-way through the set = of presence agents. Since any change should trigger a notification, the = watcher will see presence tuple states "flutter" all over = before (hopefully) settling down to the correct state. If the PAs are = all watching one another, and the watcher is watching all of the PAs, = then it should always (in theory) settle on the correct state, but = could be in incorrect intermediate states for a noticible period of = time.

- Complete Knowledge of State: In a 2 FSM = synchronization scenario, knowing the complete state picture is simple. = You are given it by the master FSM, and you're done. In the N-way FSM = synch scenario, you have to know the state of N FSM's. However, we do = not have a reliable mechanism for ensuring that this happens (thus the = thread on forking began once again).

I could go into more detail on some of the other = problems, but this is a good start in my view. As Jonathan points out, = who is screaming for there to be multiple PAs in the first place? We = can obviously do very well with a single presence agent because this is = how every major *widely deployed* presence model works, and people = don't seem to mind at all.

Regards,

Brian Stucker
Nortel Networks


-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, November 19, 2001 6:04 PM
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; = 'Jonathan Rosenberg';
Roy, Radhika R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim = (NET/Dallas)'; 'Ngo, Dai
(c)'; 'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202


Part 2... note that I'm addressing multiple presence = sources
specifically here, **not** the general SUB/NOT = forking problem
(that was my previous mail).

Perhaps I'm being daft, but I can't see what is so = complicated
about merging state received from two different = sources,
GIVEN THE WAY THE CPIM PRESENCE FORMAT IS = DEFINED.

I've put those nine words in all-caps because they = are crucial
to understanding what I'm trying to say.

For presence, the state information delivered by = a
concentration point in the network will contain the = state of
several different entities. This differs in no real = way (in terms
of forming a single coherent state to be rendered to = the user)
from the situation in which you receive this state = directly from
each entity.

I've given it a bit of thought, and (for presence, at = least), can
really see only two open issues if we allow multiple = PUAs to be
established by an initial SUBSCRIBE:

- How do we ensure that the presentity ID is unique? = (We could fix
  this by requiring GUIDs or similar), = and

- How do we make sure that we don't get information = about a particular
  presentity from more than one source (e.g. an = endpoint PUA and a
  concentrator) -- or, if you do (and they are = in conflict), how do
  you sort out which is authoritative? The = answer to this isn't as trivial,
  but I can think of several easy-to-implement = schemes that would make
  this work out just fine.

Neither of these are showstoppers. The first one = isn't even difficult.

That said, there have been several intelligent people = on this list
insisting that there are hordes of intractable = problems that prohibit
merging state at the subscriber end, so I must be = overlooking something
massive. It would be instructive -- and probably = more conducive to
progress -- if people would argue their points in = specific terms (such
as detailing individual problems, like the two I = describe above) instead
of just calling the entire problem set = "difficult" and throwing their
hands up.

/a

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Monday, November 19, 2001 5:35 PM
To: adam.roach; 'Jonathan Rosenberg'; Roy, Radhika = R, ALCTA; Paul Kyzivat
Cc: Robert Sparks; 'James Undery'; 'Moran Tim = (NET/Dallas)'; 'Ngo, Dai (c)';
'Brazier Lachlan'; 'simple'
Subject: RE: [Simple] 200 vs. 202


Adam,
I respect your viewpoint and the work in the event = draft, but I'm going to have
to disagree with you.
Option 1 makes the assumption that sometimes = reach-all is valid, and sometimes
it's not. It's flexible. If you want to pay = attention to an apparently
unsolicited NOTIFY that matches everything except = the TO tag from the 200 OK
from the SUBSCRIBE, go for it. If not, then you've = got a problem, squelch the
messages you don't want with the 481.
Option 2 is overkill. It might not matter to the = particular service or
mechanism being deployed if the forking behavior of = non-INVITE messages is
going to pose a problem. Not allowing forking would = be (to me) like forcing
everything to use TCP instead of UDP. Plus, it's = SIP/2.1.
Option 3 assumes that the problem of having multiple = dialogs created as part of
presence is a good thing to have in the first place. = And it's SIP/2.1.
My argument all along has been that even if the = forking issues are resolved,
there's fundamental problems with allowing multiple = subscriptions to be
created, in the case of presence. That because of = this, for presence, it is
best to very strongly recommend that only one = presence agent be in the network
at any point at time. It would not matter if forking = worked exactly how
everyone wanted it to work or not, you'd still have = serious problems.
Option 1 works for presence as far as I can see, and = does not place or pose any
restrictions on others who, for their event package, = want to loosen up the
rules a bit more. It is a client problem entirely. = The network won't even know
what is going on or care.
Am I missing something?
Regards,
Brian Stucker

------_=_NextPart_001_01C171D7.AB0EDD70-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 11:18:47 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17483 for ; Tue, 20 Nov 2001 11:18:47 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKGFjhp010108; Tue, 20 Nov 2001 11:15:45 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06160; Tue, 20 Nov 2001 11:17:08 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06149 for ; Tue, 20 Nov 2001 11:16:14 -0500 (EST) Received: from dynamicsoft.com (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fAKGDtM11787; Tue, 20 Nov 2001 10:13:55 -0600 Message-ID: <3BFA8143.7000207@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011115 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'Hakan.Jonsson@bluelabs.se'" , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] new I-D on subscribing to buddy lists 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: Tue, 20 Nov 2001 10:13:55 -0600 Content-Transfer-Encoding: 7bit Inline Jonathan Rosenberg wrote: > > > > >>-----Original Message----- >>From: Hakan.Jonsson@bluelabs.se [mailto:Hakan.Jonsson@bluelabs.se] >>Sent: Thursday, November 15, 2001 8:24 AM >>To: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' >>Subject: Re: [Simple] new I-D on subscribing to buddy lists >> >>From section 2 BLSS Operation: >> >>>The BLSS generates an immediate, empty NOTIFY as required >>> >>by [2], and >>then obtains the presence state of the users on the buddy list. >> >>Does it have done in this order? >> > > Nope. > > >>Is there anything which >>prevents the BLSS >>to subscribe to the buddylist users' presence before the user >>requests the >>subscription, and send the aggregated state in the first NOTIFY? >> > > Nothing prevents that, no. Although there may be some delay between the time the list subscription is receivced and the time the BLSS has receivced notifies from each presentity in the list. This is fine from a protocol perspective but might have some implications on application design. For that matter, it is probably not necessary to causally couple the timing of list subscription (front side) to the presentity subscriptions (back side). There are approaches a BLSS implementation could choose to increase the odds that it already has presence information for a list when the list subscription arrives. One could, for example, have back side subscriptions triggered by some other (outside the scope of the draft) event, stay up all the time, or keep most lists most recently subscribed to active and deactivate lists that have had no subscription activity for a long time. > > >>>As notifications with presence data are received, they can be passed >>> >>onwards towards the subscriber. >> >>Would it be allowable to forward the NOTIFIES from the users >>subscribed to, >>to the subscriber as is? Would there be a problem with the subscriber >>receiving NOTIFIES with an unknown Call-ID? Or could the BLSS >>reuse the >>Call-ID from the subscriber? >> > > I think they should be converted. You'll also run into sequence numbering > issues too. The content (the bodies) can simply be copied. > I think they MUST be converted, unless we are prepared to relax rules for call-leg matching at the subscriber UA. > >>From section 3.5 Notify bodies: >> >>>Since the cpim-pidf+xml type contains the identity of the presentity >>> >>within it, it is clear for which buddy the presence data applies. >> >>It would be nice if this draft could describe the behaviour >>of the BLSS if >>a presence format used for the body does NOT contain the >>identity of the >>presentity, but does instead refer to the presentity in the >>SIP headers. >> > > The point is that this function is not needed, and arguably doesn't belong > in the headers, as its a characteristic of the thing being subscribed to, > which is the buddy list itself. > > >>>The second possibility for aggregation is to use a single body type >>> >>explicitly designed to support lists of presence data. This format, >>????.... >> >>Why not use the format proposed to IMPP as specified in the >>expired draft >>draft-rosenberg-impp-buddylist-00? >> > > That is the wrong thing. draft-rosenberg-impp-buddylist is merely a list of > buddies (effectively, the thing I subscribe to); it is not a way to > represent their presence states. > > -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 Tue Nov 20 11:23:11 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17779 for ; Tue, 20 Nov 2001 11:23:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKGKOhp010200; Tue, 20 Nov 2001 11:20:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06201; Tue, 20 Nov 2001 11:22:08 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06190 for ; Tue, 20 Nov 2001 11:21:46 -0500 (EST) Received: from dynamicsoft.com (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fAKGJYM11797; Tue, 20 Nov 2001 10:19:34 -0600 Message-ID: <3BFA8296.2060308@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011115 X-Accept-Language: en-us MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: <3BFA68B2.94C6CEB2@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: Tue, 20 Nov 2001 10:19:34 -0600 Content-Transfer-Encoding: 7bit We ran into similar issues when we were trying to define how to use SDP to describe SIP based message sessions. I suspect that will be the harded part in finishing IMTP, and perhaps the part most in need of our attention. Paul Kyzivat wrote: > Jonathan - I agreed with most of what you said in this reply, but there > was one point I take issue with: > > Jonathan Rosenberg wrote: > > [snip] > > >>When an IMTP relay rewrites the SDP, the c line contains a domain name. >> > > The latest versions of SDP don't permit FQDNs in the c= line. > I never did hear why this change was made. While it often may be wise to > avoid FQDNs in sdp, it seems pretty heavy handed to forbid them, since > as you point out here there may be cases where they are useful. > > Paul > _______________________________________________ > 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 Tue Nov 20 11:25:08 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17918 for ; Tue, 20 Nov 2001 11:25:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKGMNhp010264; Tue, 20 Nov 2001 11:22:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06226; Tue, 20 Nov 2001 11:24:08 -0500 (EST) 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 LAA06215 for ; Tue, 20 Nov 2001 11:23:14 -0500 (EST) 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 fAKGLUhp010259; Tue, 20 Nov 2001 11:21:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 11:22:53 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Paul Kyzivat Cc: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: RE: [Simple] New I-D on IM transport 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, 20 Nov 2001 11:22:52 -0500 Its worth noting that this is an issue for RTP as well; if you are using some kind of RTP intermediary (perhaps even a TURN server...) you might want a domain name instead of an IP address for robustness. -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: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Tuesday, November 20, 2001 11:20 AM > To: Paul Kyzivat > Cc: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] New I-D on IM transport > > > We ran into similar issues when we were trying to define how > to use SDP > to describe SIP based message sessions. I suspect that will be the > harded part in finishing IMTP, and perhaps the part most in > need of our > attention. > > Paul Kyzivat wrote: > > > Jonathan - I agreed with most of what you said in this > reply, but there > > was one point I take issue with: > > > > Jonathan Rosenberg wrote: > > > > [snip] > > > > > >>When an IMTP relay rewrites the SDP, the c line contains a > domain name. > >> > > > > The latest versions of SDP don't permit FQDNs in the c= line. > > I never did hear why this change was made. While it often > may be wise to > > avoid FQDNs in sdp, it seems pretty heavy handed to forbid > them, since > > as you point out here there may be cases where they are useful. > > > > Paul > > _______________________________________________ > > 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 Tue Nov 20 16:27:34 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06824 for ; Tue, 20 Nov 2001 16:27:34 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKLHPhp012980; Tue, 20 Nov 2001 16:17:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07169; Tue, 20 Nov 2001 16:19:08 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07158 for ; Tue, 20 Nov 2001 16:18:38 -0500 (EST) From: adam.roach@ericsson.com Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAKLICP20922 for ; Tue, 20 Nov 2001 15:18:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAKLICa23145 for ; Tue, 20 Nov 2001 15:18:12 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA11007 for ; Tue, 20 Nov 2001 15:18:11 -0600 (CST) Reply-To: To: Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C64@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <61D824C63B99D311975E00508B0CC985030836F1@eamrcnt717.exu.ericsson.se> 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, 20 Nov 2001 15:18:10 -0600 Content-Transfer-Encoding: 7bit While I disagree with Brian and Jonathan about the problems presented by having multiple PAs in the network, I am willing to quit the topic for the sake of moving forward. I am very wary, however, of any discussions which use arguments about the general case of forking of SUBSCRIBE requests instead of those involving multiple PAs. I wouldn't have even entered the fray if the arguments presented by several parties didn't attack the very notion of SUBSCRIBE forking (instead of limiting themselves to presence in particular). So, with my capitulation, I'll attempt to enumerate what I think we've all agreed on: 1. SUBSCRIBE requests may fork. 2. Subscribers may choose to accept zero or more of the NOTIFY requests that arrive by responding to them with a 200. 3. Subscribers may choose to reject zero or more of the NOTIFY requests that arrive by responding to them with a 481. 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I don't personally care which) accept exactly one NOTIFY message with a 200, and reject all others with a 481. 5. Subscribers _to_ _presence_ _information_ select which NOTIFY to accept based on the dialog information established by the 2xx response to the SUBSCRIBE. Moving forward, then, I see two sets of problems to be addressed: Forking SUBSCRIBE: - How do we perform authentication for forked SUBSCRIBE messages? This is actually a more general problem which can be phrased "How do we perform authentication for forked XXX messages?" where XXX includes INVITE. I would *really*, *really* like to see a more general solution to this problem before we start trying to cobble something together for SUBSCRIBE. - How do we protect against the DOS attacks that Robert describes? Presence: - In a forking situation, it is likely (probable, even) that the NOTIFY requests will arrive at the subscriber before the 2xx reply to the SUBSCRIBE. Does that mean that the response to the NOTIFY requests will be suppressed until the SUBSCRIBE request completes? If so, this should be well documented in the presence event package. - Some of the arguments made against accepting multiple dialogs created by a single SUBSCRIBE were privacy based: an aggregation point must exist in the network to provide a consistent policy. Given that there is no way to enforce that only one dialog is accepted, are there any privacy concerns that can arise from rogue clients accepting all received NOTIFYs? /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 16:29:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06930 for ; Tue, 20 Nov 2001 16:29:47 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKLJMhp013047; Tue, 20 Nov 2001 16:19:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07198; Tue, 20 Nov 2001 16:21:08 -0500 (EST) 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 QAA07187 for ; Tue, 20 Nov 2001 16:20:30 -0500 (EST) 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 PAA19631 for ; Tue, 20 Nov 2001 15:20:07 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 20 Nov 2001 15:12:58 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 15:18:49 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE78072@zrc2c012.us.nortel.com> From: "Brian Stucker" To: jdrosen@dynamicsoft.com, adam.roach@ericsson.com Cc: simple@mailman.dynamicsoft.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17208.ED3B35F0" X-Orig: Subject: [Simple] Question regarding NOTIFY messages using UDP. 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, 20 Nov 2001 15:18:40 -0600 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_01C17208.ED3B35F0 Content-Type: text/plain; charset="iso-8859-1" Hi all, I have a new question for the list... In the case where a client can only use UDP to communicate with a presence server, the size of presence messages gets quite large. Would there be a problem introduced if the presence document were split up across multiple NOTIFY messages (perhaps a few presence tuples at a time)? It would be one PA sending all of the pieces of the presence document, just instead of in one NOTIFY, in many over a short period of time to avoid fragmentation issues. The only issue I see is if a client sends a fetch subscribe, it might not expect multiple NOTIFY messages, but from discussions about merging state earlier it seemed there wasn't an issue with sending the presence document in parts, just that it needs to be aggregated before sending (which it still would be). Thoughts? Brian ------_=_NextPart_001_01C17208.ED3B35F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Question regarding NOTIFY messages using UDP.

Hi all,

I have a new question for the list... =

In the case where a client can only = use UDP to communicate with a presence server, the size of presence = messages gets quite large. Would there be a problem introduced if the = presence document were split up across multiple NOTIFY messages = (perhaps a few presence tuples at a time)? It would be one PA sending = all of the pieces of the presence document, just instead of in one = NOTIFY, in many over a short period of time to avoid fragmentation = issues.

The only issue I see is if a client = sends a fetch subscribe, it might not expect multiple NOTIFY messages, = but from discussions about merging state earlier it seemed there wasn't = an issue with sending the presence document in parts, just that it = needs to be aggregated before sending (which it still would = be).

Thoughts?

Brian

------_=_NextPart_001_01C17208.ED3B35F0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 16:49:24 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07639 for ; Tue, 20 Nov 2001 16:49:24 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKLdOhp013340; Tue, 20 Nov 2001 16:39:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07298; Tue, 20 Nov 2001 16:41:07 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07287 for ; Tue, 20 Nov 2001 16:40:46 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAKLYEP26711; Tue, 20 Nov 2001 15:34:14 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAKLYEs09749; Tue, 20 Nov 2001 15:34:14 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id PAA11642; Tue, 20 Nov 2001 15:34:13 -0600 (CST) Reply-To: To: "'Brian Stucker'" , Message-ID: <61D824C63B99D311975E00508B0CC98502C66C66@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <933FADF5E673D411B8A30002A5608A0EE78072@zrc2c012.us.nortel.com> Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. 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, 20 Nov 2001 15:34:11 -0600 Content-Transfer-Encoding: 7bit Once your presence documents exceed 64 kbytes, this becomes a problem. This seems extremely unlikely. In the short term, I propose that you send complete presence documents. As they become larger than the path MTU, you might see a nominal increase in retransmissions, but I doubt it will become unacceptable. (This is based on implementation experience, not random guessing). For the long term (post-sip-presence-RFC), you probably want to toy around with defining a mechanism for sending state deltas, as is described in the sip-events draft. I propose that you not worry about this for now; there are more pressing issues. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, November 20, 2001 3:19 PM To: jdrosen@dynamicsoft.com; adam.roach@ericsson.com Cc: simple@mailman.dynamicsoft.com Subject: Question regarding NOTIFY messages using UDP. Hi all, I have a new question for the list... In the case where a client can only use UDP to communicate with a presence server, the size of presence messages gets quite large. Would there be a problem introduced if the presence document were split up across multiple NOTIFY messages (perhaps a few presence tuples at a time)? It would be one PA sending all of the pieces of the presence document, just instead of in one NOTIFY, in many over a short period of time to avoid fragmentation issues. The only issue I see is if a client sends a fetch subscribe, it might not expect multiple NOTIFY messages, but from discussions about merging state earlier it seemed there wasn't an issue with sending the presence document in parts, just that it needs to be aggregated before sending (which it still would be). Thoughts? Brian _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 17:08:02 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08500 for ; Tue, 20 Nov 2001 17:08:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKLtOhp013564; Tue, 20 Nov 2001 16:55:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07382; Tue, 20 Nov 2001 16:57:08 -0500 (EST) 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 QAA07370 for ; Tue, 20 Nov 2001 16:56:44 -0500 (EST) 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 PAA01339 for ; Tue, 20 Nov 2001 15:56:21 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Tue, 20 Nov 2001 15:49:19 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 15:55:10 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE78115@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , simple Cc: "Alex Nava" , "Patrick Sollee" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1720E.03823CA0" X-Orig: Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. 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, 20 Nov 2001 15:55:05 -0600 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_01C1720E.03823CA0 Content-Type: text/plain; charset="iso-8859-1" 64kbyte? I thought the standard MTU size for a UDP packet was something on the order of 1500 bytes, that's significantly lower. Maybe we're talking about two different things. In the case that no previous presence document has ever been sent, or even if the diff is greater than the MTU, you still run into a problem. Therefore, the simplest, and most expedient solution (to me, where TCP or the like can't be used very easily) would be to allow the message body in the NOTIFY be "packetized" so that it can safely fit into a UDP MTU, and sent in pieces instead. Is this a horribly bad thing, or something that we can toy around with now? Presence is going to encounter (hopefully) a lot of residential firewalls that it'll have to contend with, where a connection-oriented transport cannot be initiated or maintained easily by the network. I'm not even convinced this is an events draft item to worry about, really. I didn't notice anything in your draft that really precludes this behavoir. Can it be included with a caveat emptor disclaimer? Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Tuesday, November 20, 2001 3:34 PM To: Stucker, Brian [NGB:B635:EXCH]; simple Subject: RE: Question regarding NOTIFY messages using UDP. Once your presence documents exceed 64 kbytes, this becomes a problem. This seems extremely unlikely. In the short term, I propose that you send complete presence documents. As they become larger than the path MTU, you might see a nominal increase in retransmissions, but I doubt it will become unacceptable. (This is based on implementation experience, not random guessing). For the long term (post-sip-presence-RFC), you probably want to toy around with defining a mechanism for sending state deltas, as is described in the sip-events draft. I propose that you not worry about this for now; there are more pressing issues. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, November 20, 2001 3:19 PM To: jdrosen@dynamicsoft.com; adam.roach@ericsson.com Cc: simple@mailman.dynamicsoft.com Subject: Question regarding NOTIFY messages using UDP. Hi all, I have a new question for the list... In the case where a client can only use UDP to communicate with a presence server, the size of presence messages gets quite large. Would there be a problem introduced if the presence document were split up across multiple NOTIFY messages (perhaps a few presence tuples at a time)? It would be one PA sending all of the pieces of the presence document, just instead of in one NOTIFY, in many over a short period of time to avoid fragmentation issues. The only issue I see is if a client sends a fetch subscribe, it might not expect multiple NOTIFY messages, but from discussions about merging state earlier it seemed there wasn't an issue with sending the presence document in parts, just that it needs to be aggregated before sending (which it still would be). Thoughts? Brian ------_=_NextPart_001_01C1720E.03823CA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question regarding NOTIFY messages using UDP.

64kbyte? I thought the standard MTU size for a UDP = packet was something on the
order of 1500 bytes, that's significantly lower. = Maybe we're talking about two different things.

In the case that no previous presence document has = ever been sent, or even if the diff is greater than the MTU, you still = run into a problem. Therefore, the simplest, and most expedient = solution (to me, where TCP or the like can't be used very easily) would = be to allow the message body in the NOTIFY be "packetized" so = that it can safely fit into a UDP MTU, and sent in pieces = instead.

Is this a horribly bad thing, or something that we = can toy around with now? Presence is going to encounter (hopefully) a = lot of residential firewalls that it'll have to contend with, where a = connection-oriented transport cannot be initiated or maintained easily = by the network.

I'm not even convinced this is an events draft item = to worry about, really. I didn't notice anything in your draft that = really precludes this behavoir. Can it be included with a caveat emptor = disclaimer?

Brian Stucker

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Tuesday, November 20, 2001 3:34 PM
To: Stucker, Brian [NGB:B635:EXCH]; simple
Subject: RE: Question regarding NOTIFY messages = using UDP.


Once your presence documents exceed 64 kbytes, this = becomes a
problem. This seems extremely unlikely.

In the short term, I propose that you send complete = presence
documents. As they become larger than the path MTU, = you might
see a nominal increase in retransmissions, but I = doubt it will
become unacceptable. (This is based on = implementation
experience, not random guessing).

For the long term (post-sip-presence-RFC), you = probably want to
toy around with defining a mechanism for sending = state deltas,
as is described in the sip-events draft. I propose = that you not
worry about this for now; there are more pressing = issues.

/a

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Tuesday, November 20, 2001 3:19 PM
To: jdrosen@dynamicsoft.com; = adam.roach@ericsson.com
Cc: simple@mailman.dynamicsoft.com
Subject: Question regarding NOTIFY messages using = UDP.


Hi all,
I have a new question for the list...
In the case where a client can only use UDP to = communicate with a presence
server, the size of presence messages gets quite = large. Would there be a
problem introduced if the presence document were = split up across multiple
NOTIFY messages (perhaps a few presence tuples at a = time)? It would be one PA
sending all of the pieces of the presence document, = just instead of in one
NOTIFY, in many over a short period of time to avoid = fragmentation issues.
The only issue I see is if a client sends a fetch = subscribe, it might not
expect multiple NOTIFY messages, but from = discussions about merging state
earlier it seemed there wasn't an issue with sending = the presence document in
parts, just that it needs to be aggregated before = sending (which it still would
be).
Thoughts?
Brian

------_=_NextPart_001_01C1720E.03823CA0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 17:30:26 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09319 for ; Tue, 20 Nov 2001 17:30:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKMRQhp013930; Tue, 20 Nov 2001 17:27:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07495; Tue, 20 Nov 2001 17:29:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07484 for ; Tue, 20 Nov 2001 17:28:34 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAKMH4P13354; Tue, 20 Nov 2001 16:17:04 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAKMH4R03313; Tue, 20 Nov 2001 16:17:04 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id QAA15472; Tue, 20 Nov 2001 16:17:03 -0600 (CST) Reply-To: To: "'Brian Stucker'" , "adam.roach" , "simple" Cc: "Alex Nava" , "Patrick Sollee" Message-ID: <61D824C63B99D311975E00508B0CC98502C66C69@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <933FADF5E673D411B8A30002A5608A0EE78115@zrc2c012.us.nortel.com> Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. 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, 20 Nov 2001 16:17:01 -0600 Content-Transfer-Encoding: 7bit This is a commonly misunderstood thing about MTUs. The IP layer (either of your machine or of a router on the path of your communications) will break up any large UDP packets into fragments to make them fit in the next-hop MTU. Reassembly of fragmented packets is performed at the receiver end -- once again, at the IP layer. Note that all of this is transparent to the application. The recommendation to keep messages smaller than a path MTU (or 1500 bytes, which is a reasonable guess) is to prevent this fragmentation. The reasons to avoid fragmentation is that it causes a nominal increase in the chance that a packet is dropped (any missing fragment invalidates the whole packet), and that it may consume additional (usually kernel) resources at the receiving end as packets are being reconstituted. Neither of these consequences is particularly dire, which is why I proposed that we can address this problem later. Technically, the draft as it's currently written *does* preclude the behavior you propose. The current version gives packages two choices: 1. Always send complete state 2. Send complete state in response to SUBSCRIBEs, and deltas in response to state changes. Your proposal would be a third option -- one that opens up a whole host of issues with little or no gain. Let's not waste cycles discussing this. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, November 20, 2001 3:55 PM To: adam.roach; simple Cc: Alex Nava; Patrick Sollee Subject: RE: Question regarding NOTIFY messages using UDP. 64kbyte? I thought the standard MTU size for a UDP packet was something on the order of 1500 bytes, that's significantly lower. Maybe we're talking about two different things. In the case that no previous presence document has ever been sent, or even if the diff is greater than the MTU, you still run into a problem. Therefore, the simplest, and most expedient solution (to me, where TCP or the like can't be used very easily) would be to allow the message body in the NOTIFY be "packetized" so that it can safely fit into a UDP MTU, and sent in pieces instead. Is this a horribly bad thing, or something that we can toy around with now? Presence is going to encounter (hopefully) a lot of residential firewalls that it'll have to contend with, where a connection-oriented transport cannot be initiated or maintained easily by the network. I'm not even convinced this is an events draft item to worry about, really. I didn't notice anything in your draft that really precludes this behavoir. Can it be included with a caveat emptor disclaimer? Brian Stucker _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 17:34:47 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09485 for ; Tue, 20 Nov 2001 17:34:46 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKMWNhp014012; Tue, 20 Nov 2001 17:32:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07530; Tue, 20 Nov 2001 17:34:08 -0500 (EST) Received: from oe-mp2.bizmailsrvcs.net (oe-mp2pub.managedmail.com [206.46.164.23]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07519 for ; Tue, 20 Nov 2001 17:34:00 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20011120223235.CJOX22528.oe-mp2.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Tue, 20 Nov 2001 16:32:35 -0600 Received: from tharvinis ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with SMTP id <20011120223332.GBEG17494.oe-ismta1.bizmailsrvcs.net@tharvinis>; Tue, 20 Nov 2001 16:33:32 -0600 From: "Theodore Havinis" To: "Jonathan Rosenberg" Cc: 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 V6.00.2600.0000 Subject: [Simple] Buddy list per User per Event service association ??? 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, 20 Nov 2001 14:38:00 -0800 Content-Transfer-Encoding: 7bit Hi, I did sent this mail out last Sunday but seems got lost. Apologies if people received it twice. I have two questions for clarifications. I'd appreciate your feedback. Clarification-I: Is it possible with the model you describe to build a buddy-list tree whereby each User has separate buddy lists for separate services ie effectively a buddy list for telephony buddies (ie buddies who want to subscribe to his telephony event), a separate one for IM buddies, or even distinguish between a buddy list for 'business telephony buddies' and a buddy list for 'family telephony buddies'. Example: A user gets a subscription from an operator for telephony service, IM service, Voice Mail service etc. and he would like to build the following scenario that reach him via telephony you should become part of his telephony-buddies, for as long as needed ie just for the duration of the call or longer. IM event Telephony event VoiceMail event |-----------| |--------------|------------| |---------------| | | | | | | | fam.BLSS buz.BLSS fam.BLSS friend.BLSS buz.BLSS friends.BLSS buz.BLSS The sum of BLSS's is the User's BLSS which resides with his home operator or 3rd party-provider. So, is that possible to be done when combining buddy-lists, events etc. based on the buddy-list draft and on the event draft from Adam R. and also should all these events and buddy lists be registered with IANA ??? Clarification-II: I believe it would be good if you could explain the connection between the 'watcherinfo' draft and this draft. In my understanding with the watcherinfo one can start creating buddy lists as well, ie allow those watchers requesting my presence information to subscribe to my presence. Kind Rgds Theodore _____________________________________ Theodore V. Havinis Openwave Systems Inc. 1400 Seaport Blvd. Redwood City, CA 94063, USA email: theodore.havinis@openwave.com mobile: (650) 776-7249 fixed : (650) 480-2628 GSM: (+44) 77-4073-5811 http://www.openwave.com _____________________________________ _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 18:28:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10533 for ; Tue, 20 Nov 2001 18:28:11 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKNPPhp014411; Tue, 20 Nov 2001 18:25:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07706; Tue, 20 Nov 2001 18:27:08 -0500 (EST) 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 SAA07694 for ; Tue, 20 Nov 2001 18:26:59 -0500 (EST) 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 RAA24140 for ; Tue, 20 Nov 2001 17:26:34 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Tue, 20 Nov 2001 17:22:24 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Nov 2001 17:25:21 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE7823B@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , "adam.roach" , simple Cc: "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1721A.9AA5FC50" Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. 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, 20 Nov 2001 17:25:13 -0600 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_01C1721A.9AA5FC50 Content-Type: text/plain; charset="iso-8859-1" Ok, you've really got me confused now. I even went off to RFC-0760 (IP) and RFC-0768 (UDP) to make sure that I wasn't off in the weeds. Even bis-05 SIP talks about MTU problems. I don't think I'm off in the weeds, but I see what you're referring to. I now see what you're getting at with the 64k size (maximum datagram size), but since IP makes no guarantee that any particular packet reaches it's destination, it's really IP that is the problem. I see what you're getting at with the UDP packet being fragmented to the IP next-hop MTU size, but that means that portions of the UDP packet may go missing and unknown since IP doesn't do anything to ensure that any particular datagram makes it to the destination. What's worse, is popular operating systems such as Microsoft Windows (with the possible exception of XP) specifically drops any datagram exceeding the MTU value until it receives an ARP response for the first datagram (thus guaranteeing it to drop all of the portions of the UDP packet, except for the very last one: http://support.microsoft.com/support/kb/articles/q233/4/01.asp). Which brings me back to my original question, and I hope I'm not seen as wasting time with this. Given if a UDP packet that exceeds the maximum MTU size will be fragmented, and that the IP layer does not guarantee that any particular datagram gets to it's destination (thus creating a need for retransmissions), or that the pieces will arrive in any particular order, is it acceptible to send multiple NOTIFY messages in order to packetize the message body for transport over UDP in a more reliable method based on an expected MTU size (ala RFC-1161). That's all I'm asking... Perhaps you could expound on the issues this would create? I don't see any difference in allowing multiple state agents to report pieces of the resource state being watched as different from having one state agent report the resource state in pieces. The gain in doing so is to help alleviate issues that arise with very common NAT/firewall implementations, where solving these issues with TCP or a similar protocol is not possible. Or, alternatively, can you give a mechanism for traversing a NAT to deliver a NOTIFY of any given length, without using TCP? Cheers, Brian Stucker Nortel Networks -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Tuesday, November 20, 2001 4:17 PM To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; simple Cc: Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH] Subject: RE: Question regarding NOTIFY messages using UDP. This is a commonly misunderstood thing about MTUs. The IP layer (either of your machine or of a router on the path of your communications) will break up any large UDP packets into fragments to make them fit in the next-hop MTU. Reassembly of fragmented packets is performed at the receiver end -- once again, at the IP layer. Note that all of this is transparent to the application. The recommendation to keep messages smaller than a path MTU (or 1500 bytes, which is a reasonable guess) is to prevent this fragmentation. The reasons to avoid fragmentation is that it causes a nominal increase in the chance that a packet is dropped (any missing fragment invalidates the whole packet), and that it may consume additional (usually kernel) resources at the receiving end as packets are being reconstituted. Neither of these consequences is particularly dire, which is why I proposed that we can address this problem later. Technically, the draft as it's currently written *does* preclude the behavior you propose. The current version gives packages two choices: 1. Always send complete state 2. Send complete state in response to SUBSCRIBEs, and deltas in response to state changes. Your proposal would be a third option -- one that opens up a whole host of issues with little or no gain. Let's not waste cycles discussing this. /a -----Original Message----- From: Brian Stucker [mailto:bstucker@nortelnetworks.com] Sent: Tuesday, November 20, 2001 3:55 PM To: adam.roach; simple Cc: Alex Nava; Patrick Sollee Subject: RE: Question regarding NOTIFY messages using UDP. 64kbyte? I thought the standard MTU size for a UDP packet was something on the order of 1500 bytes, that's significantly lower. Maybe we're talking about two different things. In the case that no previous presence document has ever been sent, or even if the diff is greater than the MTU, you still run into a problem. Therefore, the simplest, and most expedient solution (to me, where TCP or the like can't be used very easily) would be to allow the message body in the NOTIFY be "packetized" so that it can safely fit into a UDP MTU, and sent in pieces instead. Is this a horribly bad thing, or something that we can toy around with now? Presence is going to encounter (hopefully) a lot of residential firewalls that it'll have to contend with, where a connection-oriented transport cannot be initiated or maintained easily by the network. I'm not even convinced this is an events draft item to worry about, really. I didn't notice anything in your draft that really precludes this behavoir. Can it be included with a caveat emptor disclaimer? Brian Stucker ------_=_NextPart_001_01C1721A.9AA5FC50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question regarding NOTIFY messages using UDP.

Ok, you've really got me confused now. I even went = off to RFC-0760 (IP) and
RFC-0768 (UDP) to make sure that I wasn't off in the = weeds. Even bis-05 SIP talks
about MTU problems. I don't think I'm off in the = weeds, but I see what you're referring to.

I now see what you're getting at with the 64k size = (maximum datagram size), but
since IP makes no guarantee that any particular = packet reaches it's destination, it's
really IP that is the problem. I see what you're = getting at with the UDP packet
being fragmented to the IP next-hop MTU size, but = that means that portions of the UDP
packet may go missing and unknown since IP doesn't = do anything to ensure that any
particular datagram makes it to the = destination.

What's worse, is popular operating systems such as = Microsoft Windows (with the possible exception of XP) specifically = drops any datagram exceeding the MTU value until it receives an ARP = response for the first datagram (thus guaranteeing it to drop all of = the portions of the UDP packet, except for the very last one: http://support.microsoft.com/support/kb/articles/q233/= 4/01.asp).

Which brings me back to my original question, and I = hope I'm not seen as wasting time with this. Given if a UDP packet that = exceeds the maximum MTU size will be fragmented, and that the IP layer = does not guarantee that any particular datagram gets to it's = destination (thus creating a need for retransmissions), or that the = pieces will arrive in any particular order, is it acceptible to send = multiple NOTIFY messages in order to packetize the message body for = transport over UDP in a more reliable method based on an expected MTU = size (ala RFC-1161). That's all I'm asking...

Perhaps you could expound on the issues this would = create? I don't see any difference in allowing multiple state agents to = report pieces of the resource state being watched as different from = having one state agent report the resource state in pieces.

The gain in doing so is to help alleviate issues that = arise with very common NAT/firewall implementations, where solving = these issues with TCP or a similar protocol is not possible. Or, = alternatively, can you give a mechanism for traversing a NAT to deliver = a NOTIFY of any given length, without using TCP?

Cheers,

Brian Stucker
Nortel Networks

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Tuesday, November 20, 2001 4:17 PM
To: Stucker, Brian [NGB:B635:EXCH]; adam.roach; = simple
Cc: Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick = [NGC:B680:EXCH]
Subject: RE: Question regarding NOTIFY messages = using UDP.


This is a commonly misunderstood thing about MTUs. = The IP layer
(either of your machine or of a router on the path = of your
communications) will break up any large UDP packets = into fragments
to make them fit in the next-hop MTU. Reassembly of = fragmented
packets is performed at the receiver end -- once = again, at the
IP layer.

Note that all of this is transparent to the = application.

The recommendation to keep messages smaller than a = path MTU
(or 1500 bytes, which is a reasonable guess) is to = prevent
this fragmentation. The reasons to avoid = fragmentation is
that it causes a nominal increase in the chance that = a packet
is dropped (any missing fragment invalidates the = whole packet),
and that it may consume additional (usually kernel) = resources
at the receiving end as packets are being = reconstituted.

Neither of these consequences is particularly dire, = which is
why I proposed that we can address this problem = later.

Technically, the draft as it's currently written = *does* preclude
the behavior you propose. The current version gives = packages
two choices:

1. Always send complete state
2. Send complete state in response to SUBSCRIBEs, = and deltas
   in response to state changes.

Your proposal would be a third option -- one that = opens up a
whole host of issues with little or no gain. Let's = not waste
cycles discussing this.

/a

-----Original Message-----
From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
Sent: Tuesday, November 20, 2001 3:55 PM
To: adam.roach; simple
Cc: Alex Nava; Patrick Sollee
Subject: RE: Question regarding NOTIFY messages = using UDP.


64kbyte? I thought the standard MTU size for a UDP = packet was something on the
order of 1500 bytes, that's significantly lower. = Maybe we're talking about two
different things.
In the case that no previous presence document has = ever been sent, or even if
the diff is greater than the MTU, you still run into = a problem. Therefore, the
simplest, and most expedient solution (to me, where = TCP or the like can't be
used very easily) would be to allow the message body = in the NOTIFY be
"packetized" so that it can safely fit = into a UDP MTU, and sent in pieces
instead.
Is this a horribly bad thing, or something that we = can toy around with now?
Presence is going to encounter (hopefully) a lot of = residential firewalls that
it'll have to contend with, where a = connection-oriented transport cannot be
initiated or maintained easily by the = network.
I'm not even convinced this is an events draft item = to worry about, really. I
didn't notice anything in your draft that really = precludes this behavoir. Can
it be included with a caveat emptor = disclaimer?
Brian Stucker

------_=_NextPart_001_01C1721A.9AA5FC50-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 18:57:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11369 for ; Tue, 20 Nov 2001 18:57:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAKNtPhp014641; Tue, 20 Nov 2001 18:55:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07838; Tue, 20 Nov 2001 18:57:08 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07826 for ; Tue, 20 Nov 2001 18:56:13 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAKNnfP07773; Tue, 20 Nov 2001 17:49:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAKNnfR19719; Tue, 20 Nov 2001 17:49:41 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id RAA22513; Tue, 20 Nov 2001 17:49:40 -0600 (CST) Reply-To: To: "'Brian Stucker'" , "simple" Cc: "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" Message-ID: <61D824C63B99D311975E00508B0CC98502C66C6D@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <933FADF5E673D411B8A30002A5608A0EE7823B@zrc2c012.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. 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, 20 Nov 2001 17:49:38 -0600 Content-Transfer-Encoding: 7bit >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > >Ok, you've really got me confused now. I even went off to RFC-0760 (IP) and >RFC-0768 (UDP) to make sure that I wasn't off in the weeds. Even bis-05 SIP talks >about MTU problems. It makes a recommendation. If fragmentation were really a problem, SIP would mandate behavior. As it is, it's just trying to raise awareness of some of the related issues (like the two I discuss in a previous mail). >I don't think I'm off in the weeds, but I see what you're referring to. >I now see what you're getting at with the 64k size (maximum datagram size), but >since IP makes no guarantee that any particular packet reaches it's destination, it's >really IP that is the problem. I see what you're getting at with the UDP packet >being fragmented to the IP next-hop MTU size, but that means that portions of the UDP >packet may go missing and unknown since IP doesn't do anything to ensure that any >particular datagram makes it to the destination. That's a problem even when you don't exceed the MTU. That's why SIP retransmits requests. There's a timer for reconstitution of the packet, sequence numbers, a checksum, and all sorts of goodies in the UDP fragmentation to make sure that it works. It's unreliable (but in an all-or-nothing sort of way, just like all UDP datagram transmissions) but it works. All you need is a mechanism to retransmit datagrams until they are acknowledged, and SIP provides such a mechanism. >What's worse, is popular operating systems such as Microsoft Windows >(with the possible exception of XP) specifically drops any datagram >exceeding the MTU value until it receives an ARP response for the first >datagram (thus guaranteeing it to drop all of the portions of the UDP >packet, except for the very last one: >http://support.microsoft.com/support/kb/articles/q233/4/01.asp). I have two reactions to this: 1. Are you *seriously* proposing that we add provisions in the protocol to work around Microsoft's buggy IP implementation? 2. Even with this special little Microsoft bug, it all works. The first transmission of a UDP packet to a host might get lost; however, this first transmission will load the ARP cache for the destination, and the subsequent retransmissions will progress as normal. I'm not arguing against your solution. I'm pointing out that the "problem" you are trying to solve is not a problem. It might be an inconvenience in corner cases, but it's not a problem. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 20 19:37:00 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12647 for ; Tue, 20 Nov 2001 19:37:00 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAL0YQhp014839; Tue, 20 Nov 2001 19:34:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07987; Tue, 20 Nov 2001 19:36:09 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07967 for ; Tue, 20 Nov 2001 19:35:51 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAL0ZUT09040; Tue, 20 Nov 2001 19:35:30 -0500 (EST) Received: from cisco.com (rtp-vpn1-73.cisco.com [10.82.224.73]) by cannon.cisco.com (Mirapoint) with ESMTP id AAD94150 (AUTH pkyzivat); Tue, 20 Nov 2001 19:36:50 -0500 (EST) Message-ID: <3BFAF60A.A94C6A15@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: Content-Type: text/plain; charset=us-ascii 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: Tue, 20 Nov 2001 19:32:10 -0500 Content-Transfer-Encoding: 7bit I think the question is one of how to recover from problems with media transport. Having an FQDN gives an opportunity to try some recovery strategy that doesn't involve sip signalling. I think it is possible to argue both sides convincingly as to whether this is a good thing. The alternative is that when something goes wrong with the media transport then perhaps you should use more sip signalling to recover - by doing a reinvite. This gives the opportunity to exchange new addresses in order to continue the session. But it also has the problem of getting the two endpoints to mutually understand what is going on and what recovery action to take. But I think there is a better chance of doing this with signalling than without. This may need something like a reason code (e.g. Reason: header) explaining why a reinvite is being done, and probably some SDP content that indicates what media session needs attention. (Just because you have an FQDN doesn't mean you can start using a different resolution of it at any old time. Once traffic has begun to flow the endpoint may no longer be prepared to receive on alternative addresses. This is especially a problem with comedia, where there has to be connection establishment before traffic can flow.) I posted about this some time ago, as an offshoot of the comedia discussions, but that faded away without any resolution. Perhaps it is time to resurrect it. Paul Jonathan Rosenberg wrote: > > Its worth noting that this is an issue for RTP as well; if you are using > some kind of RTP intermediary (perhaps even a TURN server...) you might want > a domain name instead of an IP address for robustness. > > -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: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Tuesday, November 20, 2001 11:20 AM > > To: Paul Kyzivat > > Cc: Jonathan Rosenberg; simple@mailman.dynamicsoft.com > > Subject: Re: [Simple] New I-D on IM transport > > > > > > We ran into similar issues when we were trying to define how > > to use SDP > > to describe SIP based message sessions. I suspect that will be the > > harded part in finishing IMTP, and perhaps the part most in > > need of our > > attention. > > > > Paul Kyzivat wrote: > > > > > Jonathan - I agreed with most of what you said in this > > reply, but there > > > was one point I take issue with: > > > > > > Jonathan Rosenberg wrote: > > > > > > [snip] > > > > > > > > >>When an IMTP relay rewrites the SDP, the c line contains a > > domain name. > > >> > > > > > > The latest versions of SDP don't permit FQDNs in the c= line. > > > I never did hear why this change was made. While it often > > may be wise to > > > avoid FQDNs in sdp, it seems pretty heavy handed to forbid > > them, since > > > as you point out here there may be cases where they are useful. > > > > > > Paul > > > _______________________________________________ > > > 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 Nov 21 01:39:54 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23799 for ; Wed, 21 Nov 2001 01:39:54 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAL6bRhp015771; Wed, 21 Nov 2001 01:37:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09137; Wed, 21 Nov 2001 01:39:08 -0500 (EST) 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 BAA09126 for ; Wed, 21 Nov 2001 01:38:19 -0500 (EST) 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 fAL6aYhp015760; Wed, 21 Nov 2001 01:36:34 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 01:37:57 -0500 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , Jonathan Rosenberg , "'sip@ietf.org'" Cc: Ben Campbell , simple@mailman.dynamicsoft.com Subject: RE: [Simple] New I-D on IM transport 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: Wed, 21 Nov 2001 01:37:57 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, November 20, 2001 7:32 PM > To: Jonathan Rosenberg > Cc: Ben Campbell; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] New I-D on IM transport > > > I think the question is one of how to recover from problems with media > transport. Having an FQDN gives an opportunity to try some recovery > strategy that doesn't involve sip signalling. I think it is > possible to > argue both sides convincingly as to whether this is a good thing. > > The alternative is that when something goes wrong with the media > transport then perhaps you should use more sip signalling to recover - > by doing a reinvite. Indeed. I have in fact written a draft on doing just that: http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt > This gives the opportunity to exchange new > addresses in order to continue the session. But it also has > the problem > of getting the two endpoints to mutually understand what is > going on and > what recovery action to take. Its somewhat complicated when intermediaries are in the picture. A proxy in the middle which has rewritted the SDP to point to an intermediary that has now failed, needs to recognize that a re-INVITE is an opportunity to update the SDP to point to a new intermediary. Whether the proxy that has done this rewrite can realize that the intermediary has failed - well, thats hard. This would be an argument for a media solution (i.e., using domain names in SDP and using an alternate when media fails), as it wouldn't require the proxy to know that the intermediary has failed. On the other hand, a signaling solution will work better when the failure requires some kind of state transfer or reconstitution (of the sorts discussed in the draft above). > But I think there is a better chance of > doing this with signalling than without. This may need > something like a > reason code (e.g. Reason: header) explaining why a reinvite is being > done, and probably some SDP content that indicates what media session > needs attention. Its not clear to me that a reason is needed. THe above draft does not require one. Its effectively the responsibility of elements "next to" the ones that failed to detect this condition and handle the re-INVITE appropriately. > I posted about this some time ago, as an offshoot of the comedia > discussions, but that faded away without any resolution. Perhaps it is > time to resurrect it. Yes, this is an important issue, and not really a simple one at all (and thus the addition of sip to the cc list). -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 Nov 21 01:49:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25201 for ; Wed, 21 Nov 2001 01:49:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAL6lMhp015844; Wed, 21 Nov 2001 01:47:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09186; Wed, 21 Nov 2001 01:49:07 -0500 (EST) 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 BAA09175 for ; Wed, 21 Nov 2001 01:48:21 -0500 (EST) 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 fAL6kahp015837; Wed, 21 Nov 2001 01:46:36 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 01:47:59 -0500 Message-ID: From: Jonathan Rosenberg To: "'Theodore Havinis'" , Jonathan Rosenberg Cc: 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] RE: Buddy list per User per Event service association ??? 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, 21 Nov 2001 01:47:58 -0500 > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Tuesday, November 20, 2001 5:38 PM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: Buddy list per User per Event service association ??? > > I have two questions for clarifications. I'd appreciate your feedback. > > Clarification-I: Is it possible with the model you describe to build a > buddy-list tree > whereby each User has separate buddy lists for separate services ie > effectively a buddy list > for telephony buddies (ie buddies who want to subscribe to > his telephony > event), a separate > one for IM buddies, or even distinguish between a buddy list > for 'business > telephony > buddies' and a buddy list for 'family telephony buddies'. Of course. A buddy list is just a named resource. I can subscribe to any named resource - sip:friends@foo.com, sip:family@foo.com, etc., so long as those resources are defined. > > Example: A user gets a subscription from an operator for > telephony service, > IM service, Voice Mail service etc. > and he would like to build the following scenario that reach him via > telephony you should become part of his > telephony-buddies, for as long as needed ie just for the > duration of the > call or longer. > > > IM event Telephony event > VoiceMail > event > |-----------| |--------------|------------| > |---------------| > | | | | | | > | > fam.BLSS buz.BLSS fam.BLSS friend.BLSS buz.BLSS > friends.BLSS buz.BLSS > > The sum of BLSS's is the User's BLSS which resides with his > home operator or > 3rd party-provider. I'm afraid you've lost me here. Just to be clear we are talking about the same thing - my buddy list is the set of people I want to learn presence about. In existing systems, this is the list of names you see on your own messenger tool. Rather than subscribing to each one individually, I can subscribe to sip:mybuddies@foo.com, and the server handling mybuddies@foo.com generates subscriptions for all the users in my list. > > So, is that possible to be done when combining buddy-lists, > events etc. > based on the buddy-list draft and on the > event draft from Adam R. and also should all these events and > buddy lists be > registered with IANA ??? You wouldn't IANA register buddy lists any more than you would IANA register user names. > > Clarification-II: > I believe it would be good if you could explain the > connection between the > 'watcherinfo' draft and this draft. > In my understanding with the watcherinfo one can start > creating buddy lists > as well, ie allow those watchers requesting > my presence information to subscribe to my presence. They are basically comverses of each other: A buddy list is the set of people I want to subscribe to (i.e., the set of people whose presence I want to learn) The watcher list is the set of people who want to subscribe to me (which includes those that have successfully subscribed and those who are merely pending). Both are lists, but represent different entities. A buddy list benefits a subscriber, a watcher list is for a presentity. I can set up authorization policy as a list that contains those folks that are allowed to subscribe to me. Call this the "authorized watcher list". It may so happen that my authorized watcher list is the same as my buddy list, but that is not necessary; these are fundamentally different lists as far as the protocol/architecture is concerned. They may be the same for a particular deployment of a real service, but thats a separate matter. -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 Nov 21 01:59:59 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26629 for ; Wed, 21 Nov 2001 01:59:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAL6vQhp015928; Wed, 21 Nov 2001 01:57:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09236; Wed, 21 Nov 2001 01:59:08 -0500 (EST) 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 BAA09225 for ; Wed, 21 Nov 2001 01:58:59 -0500 (EST) 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 fAL6v5hp015919; Wed, 21 Nov 2001 01:57:05 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 01:58:28 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , "'Brian Stucker'" , simple Cc: Alex Nava , Patrick Sollee , Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. 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: Wed, 21 Nov 2001 01:58:27 -0500 I agree with Adam that defining a SIP specific fragmentation is a bad thing. We have discussed this on the SIP list and it has been quickly squashed. For simple, a real delta versioning solution is the best thing. Another solution is TCP, which is generally better as far as firewall/nat traversal is concerned, not worse, and has none of these fragmentation issues. -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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Tuesday, November 20, 2001 6:50 PM > To: 'Brian Stucker'; simple > Cc: Alex Nava; Patrick Sollee; Sanjoy Sen > Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. > > > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > > > >Ok, you've really got me confused now. I even went off to > RFC-0760 (IP) and > >RFC-0768 (UDP) to make sure that I wasn't off in the weeds. > Even bis-05 SIP > talks > >about MTU problems. > > It makes a recommendation. If fragmentation were really a > problem, SIP would > mandate behavior. As it is, it's just trying to raise > awareness of some of > the related issues (like the two I discuss in a previous mail). > > >I don't think I'm off in the weeds, but I see what you're > referring to. > >I now see what you're getting at with the 64k size (maximum > datagram size), > but > >since IP makes no guarantee that any particular packet reaches it's > destination, it's > >really IP that is the problem. I see what you're getting at > with the UDP > packet > >being fragmented to the IP next-hop MTU size, but that means > that portions of > the UDP > >packet may go missing and unknown since IP doesn't do > anything to ensure that > any > >particular datagram makes it to the destination. > > That's a problem even when you don't exceed the MTU. That's why > SIP retransmits requests. > > There's a timer for reconstitution of the packet, sequence numbers, > a checksum, and all sorts of goodies in the UDP fragmentation to make > sure that it works. It's unreliable (but in an all-or-nothing sort > of way, just like all UDP datagram transmissions) but it works. All > you need is a mechanism to retransmit datagrams until they are > acknowledged, and SIP provides such a mechanism. > > >What's worse, is popular operating systems such as Microsoft Windows > >(with the possible exception of XP) specifically drops any datagram > >exceeding the MTU value until it receives an ARP response > for the first > >datagram (thus guaranteeing it to drop all of the portions of the UDP > >packet, except for the very last one: > >http://support.microsoft.com/support/kb/articles/q233/4/01.asp). > > I have two reactions to this: > > 1. Are you *seriously* proposing that we add provisions in the > protocol to work around Microsoft's buggy IP implementation? > > 2. Even with this special little Microsoft bug, it all works. > The first transmission of a UDP packet to a host might get > lost; however, this first transmission will load the ARP cache > for the destination, and the subsequent retransmissions will > progress as normal. > > I'm not arguing against your solution. I'm pointing out that > the "problem" you are trying to solve is not a problem. It might > be an inconvenience in corner cases, but it's not a problem. > > /a > > _______________________________________________ > 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 Nov 21 06:53:55 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09509 for ; Wed, 21 Nov 2001 06:53:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALBpRhp016540; Wed, 21 Nov 2001 06:51:27 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10129; Wed, 21 Nov 2001 06:53:08 -0500 (EST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10118 for ; Wed, 21 Nov 2001 06:52:47 -0500 (EST) Received: from libero.it (193.70.192.42) by smtp2.libero.it (6.0.032) id 3BEFF161002E5E4F for simple@mailman.dynamicsoft.com; Wed, 21 Nov 2001 12:52:25 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q??=" To: simple@mailman.dynamicsoft.com X-XaM3-API-Version: 2.5 X-type: 0 X-SenderIP: 193.205.164.113 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id GAA10118 Subject: [Simple] =?iso-8859-1?Q?multiple_subscribe?= 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, 21 Nov 2001 12:52:24 +0100 Content-Transfer-Encoding: 8bit hi, i've the following problem: what happened if a watcher send a SUBSCRIBE request to the PA (for example: PA1), and after, when the previous SUBSCRIBE request hasn't been terminated, the watcher send another SUBSCRIBE request (not refresh, with diffent call-id and relative tags) to the same PA? is it possible that, in this situation, the PA discard the second request or the first? _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 10:05:18 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18414 for ; Wed, 21 Nov 2001 10:05:18 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALF2Rhp017494; Wed, 21 Nov 2001 10:02:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10724; Wed, 21 Nov 2001 10:04:11 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10158 for ; Wed, 21 Nov 2001 06:59:25 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09780; Wed, 21 Nov 2001 06:59:03 -0500 (EST) Message-Id: <200111211159.GAA09780@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: simple@mailman.dynamicsoft.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [Simple] I-D ACTION:draft-mankin-im-session-guide-00.txt 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, 21 Nov 2001 06:59:03 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Instant Message Sessions Author(s) : A. Mankin, J. Peterson Filename : draft-mankin-im-session-guide-00.txt Pages : 14 Date : 20-Nov-01 This document recommends a set of guidelines for session-based instant messaging, focusing particularly on security properties, the selection of transport protocols and the effects of network intermediaries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mankin-im-session-guide-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mankin-im-session-guide-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mankin-im-session-guide-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011120151609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mankin-im-session-guide-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mankin-im-session-guide-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011120151609.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 10:07:44 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18532 for ; Wed, 21 Nov 2001 10:07:44 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALF5Lhp017566; Wed, 21 Nov 2001 10:05:21 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10755; Wed, 21 Nov 2001 10:07:07 -0500 (EST) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10735 for ; Wed, 21 Nov 2001 10:05:53 -0500 (EST) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GN500JH5OK3AE@firewall.wcom.com> for simple@mailman.dynamicsoft.com; Wed, 21 Nov 2001 15:04:52 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GN500F01OJSAU@dgismtp01.wcomnet.com>; Wed, 21 Nov 2001 15:04:51 +0000 (GMT) Received: from omzexch006.mcit.com ([166.37.194.37]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GN500EC7OJQ0F@dgismtp01.wcomnet.com>; Wed, 21 Nov 2001 15:04:39 +0000 (GMT) Received: by omzexch006 with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 15:04:38 +0000 Content-return: allowed From: "Ngo, Dai (c)" Subject: RE: [Simple] multiple subscribe To: "'salvatore.loreto@libero.it'" , simple@mailman.dynamicsoft.com Message-id: <492EB4A3F68CD411ABE800508B69362E6C4E97@RIPEXCH002.wcomnet.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Wed, 21 Nov 2001 15:04:35 +0000 Different call-id establishes a different dialog. You will end up with two subscriptions. -----Original Message----- From: salvatore.loreto@libero.it [mailto:salvatore.loreto@libero.it] Sent: Wednesday, November 21, 2001 5:52 AM To: simple@mailman.dynamicsoft.com Subject: [Simple] multiple subscribe hi, i've the following problem: what happened if a watcher send a SUBSCRIBE request to the PA (for example: PA1), and after, when the previous SUBSCRIBE request hasn't been terminated, the watcher send another SUBSCRIBE request (not refresh, with diffent call-id and relative tags) to the same PA? is it possible that, in this situation, the PA discard the second request or the first? _______________________________________________ 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 Nov 21 10:11:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18797 for ; Wed, 21 Nov 2001 10:11:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALF9Mhp017654; Wed, 21 Nov 2001 10:09:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10787; Wed, 21 Nov 2001 10:11:08 -0500 (EST) 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 KAA10776 for ; Wed, 21 Nov 2001 10:10:27 -0500 (EST) 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 fALF8fhp017644; Wed, 21 Nov 2001 10:08:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 10:10:05 -0500 Message-ID: From: Jonathan Rosenberg To: "'salvatore.loreto@libero.it'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] multiple subscribe 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: Wed, 21 Nov 2001 10:10:04 -0500 > -----Original Message----- > From: salvatore.loreto@libero.it [mailto:salvatore.loreto@libero.it] > Sent: Wednesday, November 21, 2001 6:52 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] multiple subscribe > > > hi, > i've the following problem: > > what happened > if a watcher send a SUBSCRIBE request to the PA (for example: PA1), > and after, when the previous SUBSCRIBE request hasn't been terminated, > the watcher send another SUBSCRIBE request (not refresh, with diffent > call-id and relative tags) to the same PA? Two separate subscriptions are created. > > is it possible that, in this situation, the PA discard the second > request or the first? No. The PA would not correlate them together; they are separate subscriptions. There are frequently good reasons for having two separate subscriptions from the same user (different apps on behalf of the same user, for example). -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 Nov 21 10:15:59 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18977 for ; Wed, 21 Nov 2001 10:15:58 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALFDOhp017775; Wed, 21 Nov 2001 10:13:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10844; Wed, 21 Nov 2001 10:15:09 -0500 (EST) Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10831 for ; Wed, 21 Nov 2001 10:14:27 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA21256; Wed, 21 Nov 2001 10:05:30 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ATD02099; Wed, 21 Nov 2001 10:05:38 -0500 (EST) Message-Id: <4.3.2.7.2.20011121100452.00b1eb80@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Jonathan Rosenberg From: Michael Hammer Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. Cc: "'adam.roach@ericsson.com'" , "'Brian Stucker'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 21 Nov 2001 10:10:46 -0500 Jonathan, While not favoring any fragmentation mechanism for SIP, does this preclude any implementation (higher level application using SIP) from choosing to send the body of the Notifies as incremental parts? It would seem that the SIP-level mechanisms would be unaware of the full nature of the body which it carries and should place no restrictions on that body. That is, it provides no mechanism nor precludes use of such a mechanism. Mike At 01:58 AM 11/21/2001 -0500, Jonathan Rosenberg wrote: >I agree with Adam that defining a SIP specific fragmentation is a bad thing. >We have discussed this on the SIP list and it has been quickly squashed. > >For simple, a real delta versioning solution is the best thing. > >Another solution is TCP, which is generally better as far as firewall/nat >traversal is concerned, not worse, and has none of these fragmentation >issues. > >-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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Tuesday, November 20, 2001 6:50 PM > > To: 'Brian Stucker'; simple > > Cc: Alex Nava; Patrick Sollee; Sanjoy Sen > > Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. > > > > > > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > > > > > >Ok, you've really got me confused now. I even went off to > > RFC-0760 (IP) and > > >RFC-0768 (UDP) to make sure that I wasn't off in the weeds. > > Even bis-05 SIP > > talks > > >about MTU problems. > > > > It makes a recommendation. If fragmentation were really a > > problem, SIP would > > mandate behavior. As it is, it's just trying to raise > > awareness of some of > > the related issues (like the two I discuss in a previous mail). > > > > >I don't think I'm off in the weeds, but I see what you're > > referring to. > > >I now see what you're getting at with the 64k size (maximum > > datagram size), > > but > > >since IP makes no guarantee that any particular packet reaches it's > > destination, it's > > >really IP that is the problem. I see what you're getting at > > with the UDP > > packet > > >being fragmented to the IP next-hop MTU size, but that means > > that portions of > > the UDP > > >packet may go missing and unknown since IP doesn't do > > anything to ensure that > > any > > >particular datagram makes it to the destination. > > > > That's a problem even when you don't exceed the MTU. That's why > > SIP retransmits requests. > > > > There's a timer for reconstitution of the packet, sequence numbers, > > a checksum, and all sorts of goodies in the UDP fragmentation to make > > sure that it works. It's unreliable (but in an all-or-nothing sort > > of way, just like all UDP datagram transmissions) but it works. All > > you need is a mechanism to retransmit datagrams until they are > > acknowledged, and SIP provides such a mechanism. > > > > >What's worse, is popular operating systems such as Microsoft Windows > > >(with the possible exception of XP) specifically drops any datagram > > >exceeding the MTU value until it receives an ARP response > > for the first > > >datagram (thus guaranteeing it to drop all of the portions of the UDP > > >packet, except for the very last one: > > >http://support.microsoft.com/support/kb/articles/q233/4/01.asp). > > > > I have two reactions to this: > > > > 1. Are you *seriously* proposing that we add provisions in the > > protocol to work around Microsoft's buggy IP implementation? > > > > 2. Even with this special little Microsoft bug, it all works. > > The first transmission of a UDP packet to a host might get > > lost; however, this first transmission will load the ARP cache > > for the destination, and the subsequent retransmissions will > > progress as normal. > > > > I'm not arguing against your solution. I'm pointing out that > > the "problem" you are trying to solve is not a problem. It might > > be an inconvenience in corner cases, but it's not a problem. > > > > /a > > > > _______________________________________________ > > 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 Nov 21 10:41:49 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20562 for ; Wed, 21 Nov 2001 10:41:49 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALFdMhp018014; Wed, 21 Nov 2001 10:39:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10969; Wed, 21 Nov 2001 10:41:07 -0500 (EST) 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 KAA10958 for ; Wed, 21 Nov 2001 10:40:04 -0500 (EST) 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 fALFcIhp018007 for ; Wed, 21 Nov 2001 10:38:18 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 10:39:42 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E7FD@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Subject: [Simple] Simple working plan 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: Wed, 21 Nov 2001 10:39:10 -0500 We have just over 2 weeks before the IETF 52. Here's an update on where I think we are: * Presence - we have closure on immediate notifies - I believe we recently acheived closure on dealing with multiple NOTIFYs - we will keep the current text * WatcherInfo - little activity - this has been queued behind presence * IM (page model) - This draft has been submitted to SIP * IM (session model) - We have a guideline draft from Allison Mankin and Jon and a proposal from Jonathan et.al. Here's how we should move forward: 1. Finish the Presence draft I don't think there are any remaining open issues. The discussions did not render any large normative changes, so I propose we have Jonathan add the requested clarifications, have a small set of nit reviewers look at it and send it on (as opposed to taking it through another WGLC). 2. Finish the WatcherInfo draft Are there any issues that would keep us from polishing this off before the meeting? 3. Digest the message session drafts We need to keep a tight focus on 1 and 2 so they dont get buried in the discussion of 3. If you have a strong opinion on 3 to express, make sure you've said what you care to on 1 and 2 first. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 10:44:58 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20684 for ; Wed, 21 Nov 2001 10:44:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALFgMhp018089; Wed, 21 Nov 2001 10:42:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10997; Wed, 21 Nov 2001 10:44:07 -0500 (EST) 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 KAA10978 for ; Wed, 21 Nov 2001 10:42:20 -0500 (EST) 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 fALFeYhp018032 for ; Wed, 21 Nov 2001 10:40:34 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 10:41:58 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E7FE@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Subject: FW: [Simple] Simple working plan 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: Wed, 21 Nov 2001 10:41:43 -0500 Apologies if this appears more than once - I'm getting odd delivery errors... -------- We have just over 2 weeks before the IETF 52. Here's an update on where I think we are: * Presence - we have closure on immediate notifies - I believe we recently acheived closure on dealing with multiple NOTIFYs - we will keep the current text * WatcherInfo - little activity - this has been queued behind presence * IM (page model) - This draft has been submitted to SIP * IM (session model) - We have a guideline draft from Allison Mankin and Jon and a proposal from Jonathan et.al. Here's how we should move forward: 1. Finish the Presence draft I don't think there are any remaining open issues. The discussions did not render any large normative changes, so I propose we have Jonathan add the requested clarifications, have a small set of nit reviewers look at it and send it on (as opposed to taking it through another WGLC). 2. Finish the WatcherInfo draft Are there any issues that would keep us from polishing this off before the meeting? 3. Digest the message session drafts We need to keep a tight focus on 1 and 2 so they dont get buried in the discussion of 3. If you have a strong opinion on 3 to express, make sure you've said what you care to on 1 and 2 first. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 11:42:16 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24089 for ; Wed, 21 Nov 2001 11:42:15 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALGdVhp018642; Wed, 21 Nov 2001 11:39:32 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11183; Wed, 21 Nov 2001 11:41:08 -0500 (EST) Received: from oe-mp1.bizmailsrvcs.net (oe-mp1pub.managedmail.com [206.46.164.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11172 for ; Wed, 21 Nov 2001 11:40:21 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20011121163716.IBRU6924.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Wed, 21 Nov 2001 10:37:16 -0600 Received: from tharvinis ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with SMTP id <20011121163944.AAL27442.oe-ismta1.bizmailsrvcs.net@tharvinis>; Wed, 21 Nov 2001 10:39:44 -0600 From: "Theodore Havinis" To: "Jonathan Rosenberg" Cc: Subject: RE: [Simple] RE: Buddy list per User per Event service association ??? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: 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, 21 Nov 2001 08:44:14 -0800 Content-Transfer-Encoding: 7bit Hi Jonathan, Thanks for your comments. Please find my comments below. Kind Rgds Theo >-----Original Message----- >From: simple-admin@mailman.dynamicsoft.com >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan >Rosenberg >Sent: Tuesday, November 20, 2001 10:48 PM >To: 'Theodore Havinis'; Jonathan Rosenberg >Cc: simple@mailman.dynamicsoft.com >Subject: [Simple] RE: Buddy list per User per Event service association >??? > > > > > > >> -----Original Message----- >> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] >> Sent: Tuesday, November 20, 2001 5:38 PM >> To: Jonathan Rosenberg >> Cc: simple@mailman.dynamicsoft.com >> Subject: Buddy list per User per Event service association ??? >> >> I have two questions for clarifications. I'd appreciate your feedback. >> >> Clarification-I: Is it possible with the model you describe to build a >> buddy-list tree >> whereby each User has separate buddy lists for separate services ie >> effectively a buddy list >> for telephony buddies (ie buddies who want to subscribe to >> his telephony >> event), a separate >> one for IM buddies, or even distinguish between a buddy list >> for 'business >> telephony >> buddies' and a buddy list for 'family telephony buddies'. > >Of course. A buddy list is just a named resource. I can subscribe to any >named resource - sip:friends@foo.com, sip:family@foo.com, etc., so long as >those resources are defined. > >> >> Example: A user gets a subscription from an operator for >> telephony service, >> IM service, Voice Mail service etc. >> and he would like to build the following scenario that reach him via >> telephony you should become part of his >> telephony-buddies, for as long as needed ie just for the >> duration of the >> call or longer. >> >> >> IM event Telephony event >> VoiceMail >> event >> |-----------| |--------------|------------| >> |---------------| >> | | | | | | >> | >> fam.BLSS buz.BLSS fam.BLSS friend.BLSS buz.BLSS >> friends.BLSS buz.BLSS >> >> The sum of BLSS's is the User's BLSS which resides with his >> home operator or >> 3rd party-provider. > >I'm afraid you've lost me here. Just to be clear we are talking about the >same thing - my buddy list is the set of people I want to learn presence >about. In existing systems, this is the list of names you see on your own >messenger tool. Rather than subscribing to each one individually, I can >subscribe to sip:mybuddies@foo.com, and the server handling >mybuddies@foo.com generates subscriptions for all the users in my list. I didn't mean it differently. > So what I was trying to understand is 'where we going' when combining Events, Buddy Lists, Wacher lists since these drafts can be very powerful in some ways when combined. So here is an example of what I was trying to say in my previous email. Lets assume that John decides to call Bob for the first time. One way to provide certain screening services on behalf of Bob for the call he is receiving from John is to have John first SUBSCRIBE to the Bob's authorized buddy list for the telephony event. So, as soon as John tries to SUBSCRIBE to Bob's "call event buddy list" Bob gets notified that John wants to SUBSCRIBE to him. Bob has a number of choices: (a) reject the subscription (b) allow John to talk to Bob without allowing him joining Bob's call event buddy list (c) allow Jonh to talk to Bob, and at the same time, let him join Bob's call event buddy list If Bob allows the subscription of John to his telephony event, then John joins Bob's buddy list for telephony. Next time John calls Bob, John is already a buddy of his for the telephony event, thus getting authorized and the call gets established (assuming no other restrictions) What I describe above for the call event, can be applied to any communication mean such as IM etc. I was wondering if this one way of how we envision to make use of Events, Buddy lists in future in order to give more control to a Callee's communication. >> >> So, is that possible to be done when combining buddy-lists, >> events etc. >> based on the buddy-list draft and on the >> event draft from Adam R. and also should all these events and >> buddy lists be >> registered with IANA ??? > >You wouldn't IANA register buddy lists any more than you would >IANA register >user names. > >> >> Clarification-II: >> I believe it would be good if you could explain the >> connection between the >> 'watcherinfo' draft and this draft. >> In my understanding with the watcherinfo one can start >> creating buddy lists >> as well, ie allow those watchers requesting >> my presence information to subscribe to my presence. > >They are basically comverses of each other: > >A buddy list is the set of people I want to subscribe to (i.e., the set of >people whose presence I want to learn) > >The watcher list is the set of people who want to subscribe to me (which >includes those that have successfully subscribed and those who are merely >pending). > >Both are lists, but represent different entities. A buddy list benefits a >subscriber, a watcher list is for a presentity. > >I can set up authorization policy as a list that contains those folks that >are allowed to subscribe to me. Call this the "authorized watcher list". It >may so happen that my authorized watcher list is the same as my buddy list, >but that is not necessary; these are fundamentally different lists >as far as >the protocol/architecture is concerned. They may be the same for a >particular deployment of a real service, but thats a separate matter. Thanks, it helped. So, I have a buddy list, with buddies who subscribed to my call event, and my call event buddy list gets updated (through a watcher client) about my buddies presence, so I know who is available to be called and who isn't because they appear to be as offline. Does that make sense ? Thanks /Theo > >-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 Nov 21 13:40:40 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28976 for ; Wed, 21 Nov 2001 13:40:40 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALIbShp019586; Wed, 21 Nov 2001 13:37:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11577; Wed, 21 Nov 2001 13:39:09 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11566 for ; Wed, 21 Nov 2001 13:38:38 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12688; Wed, 21 Nov 2001 13:38:15 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12358; Wed, 21 Nov 2001 13:38:17 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 21 Nov 2001 13:38:16 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C578@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Theodore Havinis'" Cc: "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] RE: Buddy list per User per Event service associatio n ??? 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, 21 Nov 2001 13:38:15 -0500 And, it's a race to see who types the fastest..... The guy with the buddy list is John, not Bob. John has a list of buddies he sees presence for. If he wants to add Bob to his list, then he has to subscribe to Bob's presence, and indeed, Bob can decide to not let him do that. The point of the buddy list is when John logs on for the umpteenth time, instead of again subscribing to John, and Mary, and Fred, and Joe individually, he does one operation (subscribe my buddy list), and all the individual subscription actions are performed on John's behalf. If any of them failed, that "buddy" would not show presence to John. Bob may have his own buddy list, but it has the people Bob wants to see presence for. So buddy lists are for watchers. Presentities may have lists of authorized subscribers, or they may have more complex rules. So far, that is beyond our specification work. AFAIK, a buddy list is really just a shorthand equivalent to a bunch of individual subscriptions. As Jonathan notes, this duplicates what is in AIM or other commercial IM systems. In those systems, each of the buddy lists are watchers. Of course, nothing prevents Bob from being in John's buddy list, but that is up to John. It is up to Bob to decide if he will let John see his presence information, or, more precisely, what he will let him see, since it isn't binary. Brian > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Wednesday, November 21, 2001 11:44 AM > To: Jonathan Rosenberg > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] RE: Buddy list per User per Event service > association ??? > > > > Hi Jonathan, > > Thanks for your comments. > > Please find my comments below. > > Kind Rgds > Theo > > >-----Original Message----- > >From: simple-admin@mailman.dynamicsoft.com > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > >Rosenberg > >Sent: Tuesday, November 20, 2001 10:48 PM > >To: 'Theodore Havinis'; Jonathan Rosenberg > >Cc: simple@mailman.dynamicsoft.com > >Subject: [Simple] RE: Buddy list per User per Event service > association > >??? > > > > > > > > > > > > > >> -----Original Message----- > >> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > >> Sent: Tuesday, November 20, 2001 5:38 PM > >> To: Jonathan Rosenberg > >> Cc: simple@mailman.dynamicsoft.com > >> Subject: Buddy list per User per Event service association ??? > >> > >> I have two questions for clarifications. I'd appreciate > your feedback. > >> > >> Clarification-I: Is it possible with the model you > describe to build a > >> buddy-list tree > >> whereby each User has separate buddy lists for separate services ie > >> effectively a buddy list > >> for telephony buddies (ie buddies who want to subscribe to > >> his telephony > >> event), a separate > >> one for IM buddies, or even distinguish between a buddy list > >> for 'business > >> telephony > >> buddies' and a buddy list for 'family telephony buddies'. > > > >Of course. A buddy list is just a named resource. I can > subscribe to any > >named resource - sip:friends@foo.com, sip:family@foo.com, > etc., so long as > >those resources are defined. > > > >> > >> Example: A user gets a subscription from an operator for > >> telephony service, > >> IM service, Voice Mail service etc. > >> and he would like to build the following scenario that > reach him via > >> telephony you should become part of his > >> telephony-buddies, for as long as needed ie just for the > >> duration of the > >> call or longer. > >> > >> > >> IM event Telephony event > >> VoiceMail > >> event > >> |-----------| |--------------|------------| > >> |---------------| > >> | | | | | | > >> | > >> fam.BLSS buz.BLSS fam.BLSS friend.BLSS buz.BLSS > >> friends.BLSS buz.BLSS > >> > >> The sum of BLSS's is the User's BLSS which resides with his > >> home operator or > >> 3rd party-provider. > > > >I'm afraid you've lost me here. Just to be clear we are > talking about the > >same thing - my buddy list is the set of people I want to > learn presence > >about. In existing systems, this is the list of names you > see on your own > >messenger tool. Rather than subscribing to each one > individually, I can > >subscribe to sip:mybuddies@foo.com, and the server handling > >mybuddies@foo.com generates subscriptions for all the users > in my list. > > I didn't mean it differently. > > > > So what I was trying to understand is 'where we going' when combining > Events, Buddy Lists, > Wacher lists since these drafts can be very powerful in some ways when > combined. > > So here is an example of what I was trying to say in my > previous email. > > Lets assume that John decides to call Bob for the first time. > One way to provide certain screening services on behalf of > Bob for the call > he is receiving from John > is to have John first SUBSCRIBE to the Bob's authorized buddy > list for the > telephony event. > So, as soon as John tries to SUBSCRIBE to Bob's "call event > buddy list" > Bob gets notified that John wants to SUBSCRIBE to him. Bob > has a number of > choices: > (a) reject the subscription > (b) allow John to talk to Bob without allowing him joining > Bob's call event > buddy list > (c) allow Jonh to talk to Bob, and at the same time, let him > join Bob's call > event buddy list > > If Bob allows the subscription of John to his telephony > event, then John > joins Bob's > buddy list for telephony. Next time John calls Bob, John is > already a buddy > of his > for the telephony event, thus getting authorized and the call gets > established (assuming no other restrictions) > > What I describe above for the call event, can be applied to any > communication mean such as IM etc. > > I was wondering if this one way of how we envision to make > use of Events, > Buddy lists in future in order > to give more control to a Callee's communication. > > > >> > >> So, is that possible to be done when combining buddy-lists, > >> events etc. > >> based on the buddy-list draft and on the > >> event draft from Adam R. and also should all these events and > >> buddy lists be > >> registered with IANA ??? > > > >You wouldn't IANA register buddy lists any more than you would > >IANA register > >user names. > > > >> > >> Clarification-II: > >> I believe it would be good if you could explain the > >> connection between the > >> 'watcherinfo' draft and this draft. > >> In my understanding with the watcherinfo one can start > >> creating buddy lists > >> as well, ie allow those watchers requesting > >> my presence information to subscribe to my presence. > > > >They are basically comverses of each other: > > > >A buddy list is the set of people I want to subscribe to > (i.e., the set of > >people whose presence I want to learn) > > > >The watcher list is the set of people who want to subscribe > to me (which > >includes those that have successfully subscribed and those > who are merely > >pending). > > > >Both are lists, but represent different entities. A buddy > list benefits a > >subscriber, a watcher list is for a presentity. > > > >I can set up authorization policy as a list that contains > those folks that > >are allowed to subscribe to me. Call this the "authorized > watcher list". It > >may so happen that my authorized watcher list is the same as > my buddy list, > >but that is not necessary; these are fundamentally different lists > >as far as > >the protocol/architecture is concerned. > > > They may be the same for a > >particular deployment of a real service, but thats a separate matter. > > Thanks, it helped. > So, I have a buddy list, with buddies who subscribed to > my call event, and my call event buddy list gets updated > (through a watcher > client) about > my buddies presence, so I know who is available to be called > and who isn't > because they > appear to be as offline. > Does that make sense ? > > > Thanks > /Theo > > > > >-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 > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 14:25:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01206 for ; Wed, 21 Nov 2001 14:25:51 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALJNOhp019922; Wed, 21 Nov 2001 14:23:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11748; Wed, 21 Nov 2001 14:25:08 -0500 (EST) 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 OAA11735 for ; Wed, 21 Nov 2001 14:24:43 -0500 (EST) 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 NAA18753 for ; Wed, 21 Nov 2001 13:24:20 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 21 Nov 2001 13:17:18 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 13:23:10 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE787A3@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , 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_01C172C1.F2126170" 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, 21 Nov 2001 13:23:05 -0600 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_01C172C1.F2126170 Content-Type: text/plain; charset="iso-8859-1" You bring up an important point about the watcher having to wait for the response to the SUBSCRIBE before processing the NOTIFY. This could give us problems if the 200 takes a long time getting back to the watcher, and the NOTIFY, in the meantime, is just sitting there being retransmitted over and over, waiting for a response. Depending on the T1 and T2 timers being used, this could create a race condition that might cause a subscription to fail because there was no response to the immediate NOTIFY. In general, what happens when a NOTIFY to the inital SUBSCRIBE fails to be acknowledged? Does the subscription go away like it does for later NOTIFY messages? The reason I ask, is because it would seem to leave the watcher in an undefined state. What are the responsibilities of a watcher that sends a SUBSCRIBE, gets a 200, and then no NOTIFY? A possible solution would be to silently throw away and NOTIFY messages that we have not gotten a response (200) on the request to create a dialogue for (the SUBSCRIBE). If we do that, then we could wait for some period of time (say the expires header in the 200 response). If that period of time elapses without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). Thoughts? Brian -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Tuesday, November 20, 2001 3:18 PM To: simple Subject: RE: [Simple] 200 vs. 202 While I disagree with Brian and Jonathan about the problems presented by having multiple PAs in the network, I am willing to quit the topic for the sake of moving forward. I am very wary, however, of any discussions which use arguments about the general case of forking of SUBSCRIBE requests instead of those involving multiple PAs. I wouldn't have even entered the fray if the arguments presented by several parties didn't attack the very notion of SUBSCRIBE forking (instead of limiting themselves to presence in particular). So, with my capitulation, I'll attempt to enumerate what I think we've all agreed on: 1. SUBSCRIBE requests may fork. 2. Subscribers may choose to accept zero or more of the NOTIFY requests that arrive by responding to them with a 200. 3. Subscribers may choose to reject zero or more of the NOTIFY requests that arrive by responding to them with a 481. 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I don't personally care which) accept exactly one NOTIFY message with a 200, and reject all others with a 481. 5. Subscribers _to_ _presence_ _information_ select which NOTIFY to accept based on the dialog information established by the 2xx response to the SUBSCRIBE. Moving forward, then, I see two sets of problems to be addressed: Forking SUBSCRIBE: - How do we perform authentication for forked SUBSCRIBE messages? This is actually a more general problem which can be phrased "How do we perform authentication for forked XXX messages?" where XXX includes INVITE. I would *really*, *really* like to see a more general solution to this problem before we start trying to cobble something together for SUBSCRIBE. - How do we protect against the DOS attacks that Robert describes? Presence: - In a forking situation, it is likely (probable, even) that the NOTIFY requests will arrive at the subscriber before the 2xx reply to the SUBSCRIBE. Does that mean that the response to the NOTIFY requests will be suppressed until the SUBSCRIBE request completes? If so, this should be well documented in the presence event package. - Some of the arguments made against accepting multiple dialogs created by a single SUBSCRIBE were privacy based: an aggregation point must exist in the network to provide a consistent policy. Given that there is no way to enforce that only one dialog is accepted, are there any privacy concerns that can arise from rogue clients accepting all received NOTIFYs? /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C172C1.F2126170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

You bring up an important point about the watcher = having to wait for the response to the SUBSCRIBE before processing the = NOTIFY. This could give us problems if the 200 takes a long time = getting back to the watcher, and the NOTIFY, in the meantime, is just = sitting there being retransmitted over and over, waiting for a = response. Depending on the T1 and T2 timers being used, this could = create a race condition that might cause a subscription to fail because = there was no response to the immediate NOTIFY.

In general, what happens when a NOTIFY to the inital = SUBSCRIBE fails to be acknowledged?  Does the subscription go away = like it does for later NOTIFY messages? The reason I ask, is because it = would seem to leave the watcher in an undefined state. What are the = responsibilities of a watcher that sends a SUBSCRIBE, gets a 200, and = then no NOTIFY?

A possible solution would be to silently throw away = and NOTIFY messages that we have not gotten a response (200) on the = request to create a dialogue for (the SUBSCRIBE). If we do that, then = we could wait for some period of time (say the expires header in the = 200 response). If that period of time elapses without a NOTIFY, then we = send the SUBSCRIBE again (if we got a 200).

Thoughts?

Brian

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Tuesday, November 20, 2001 3:18 PM
To: simple
Subject: RE: [Simple] 200 vs. 202


While I disagree with Brian and Jonathan about the = problems presented
by having multiple PAs in the network, I am willing = to quit the topic
for the sake of moving forward.

I am very wary, however, of any discussions which use = arguments about
the general case of forking of SUBSCRIBE requests = instead of those
involving multiple PAs. I wouldn't have even entered = the fray if the
arguments presented by several parties didn't attack = the very notion
of SUBSCRIBE forking (instead of limiting themselves = to presence in
particular).

So, with my capitulation, I'll attempt to enumerate = what I think
we've all agreed on:

 1. SUBSCRIBE requests may fork.

 2. Subscribers may choose to accept zero or = more of the
    NOTIFY requests that arrive by = responding to them with
    a 200.

 3. Subscribers may choose to reject zero or = more of the
    NOTIFY requests that arrive by = responding to them with
    a 481.

 4. Subscribers _to_ _presence_ _information_ = SHOULD or MUST (I
    don't personally care which) = accept exactly one NOTIFY
    message with a 200, and reject = all others with a 481.

 5. Subscribers _to_ _presence_ _information_ = select which
    NOTIFY to accept based on the = dialog information
    established by the 2xx response = to the SUBSCRIBE.

Moving forward, then, I see two sets of problems to = be addressed:

Forking SUBSCRIBE:
  - How do we perform authentication for forked = SUBSCRIBE messages?
    This is actually a more general = problem which can be phrased
    "How do we perform = authentication for forked XXX messages?" where
    XXX includes INVITE. I would = *really*, *really* like to see a
    more general solution to this = problem before we start trying
    to cobble something together for = SUBSCRIBE.

  - How do we protect against the DOS attacks = that Robert describes?

Presence:
  - In a forking situation, it is likely = (probable, even) that the
    NOTIFY requests will arrive at = the subscriber before the 2xx
    reply to the SUBSCRIBE. Does that = mean that the response to the
    NOTIFY requests will be = suppressed until the SUBSCRIBE request
    completes? If so, this should be = well documented in the
    presence event package.

  - Some of the arguments made against accepting = multiple dialogs
    created by a single SUBSCRIBE = were privacy based: an aggregation
    point must exist in the network = to provide a consistent policy.
    Given that there is no way to = enforce that only one dialog is
    accepted, are there any privacy = concerns that can arise from
    rogue clients accepting all = received NOTIFYs?

/a

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

------_=_NextPart_001_01C172C1.F2126170-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 15:02:14 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03043 for ; Wed, 21 Nov 2001 15:02:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALJxOhp020190; Wed, 21 Nov 2001 14:59:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11872; Wed, 21 Nov 2001 15:01:08 -0500 (EST) 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 PAA11861 for ; Wed, 21 Nov 2001 15:00:53 -0500 (EST) 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 fALJwEhp020177; Wed, 21 Nov 2001 14:58:14 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 14:59:39 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brian Stucker'" , "adam.roach" , simple 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: Wed, 21 Nov 2001 14:59:39 -0500 how about this: 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it accepts the NOTIFY 2. once the response to the SUBSCRIBE comes, if its not a match for the NOTIFY, the subscriber refreshes the dialog associated with the NOTIFY, but with Expires:0, to terminate it. This avoids the tight transaction timing interdependencies at the expense of some additional higher level processing. BTW, this is really a sip-events issue not so much a simple issue. -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: Wednesday, November 21, 2001 2:23 PM To: adam.roach; simple Subject: RE: [Simple] 200 vs. 202 You bring up an important point about the watcher having to wait for the response to the SUBSCRIBE before processing the NOTIFY. This could give us problems if the 200 takes a long time getting back to the watcher, and the NOTIFY, in the meantime, is just sitting there being retransmitted over and over, waiting for a response. Depending on the T1 and T2 timers being used, this could create a race condition that might cause a subscription to fail because there was no response to the immediate NOTIFY. In general, what happens when a NOTIFY to the inital SUBSCRIBE fails to be acknowledged? Does the subscription go away like it does for later NOTIFY messages? The reason I ask, is because it would seem to leave the watcher in an undefined state. What are the responsibilities of a watcher that sends a SUBSCRIBE, gets a 200, and then no NOTIFY? A possible solution would be to silently throw away and NOTIFY messages that we have not gotten a response (200) on the request to create a dialogue for (the SUBSCRIBE). If we do that, then we could wait for some period of time (say the expires header in the 200 response). If that period of time elapses without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). Thoughts? Brian -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Tuesday, November 20, 2001 3:18 PM To: simple Subject: RE: [Simple] 200 vs. 202 While I disagree with Brian and Jonathan about the problems presented by having multiple PAs in the network, I am willing to quit the topic for the sake of moving forward. I am very wary, however, of any discussions which use arguments about the general case of forking of SUBSCRIBE requests instead of those involving multiple PAs. I wouldn't have even entered the fray if the arguments presented by several parties didn't attack the very notion of SUBSCRIBE forking (instead of limiting themselves to presence in particular). So, with my capitulation, I'll attempt to enumerate what I think we've all agreed on: 1. SUBSCRIBE requests may fork. 2. Subscribers may choose to accept zero or more of the NOTIFY requests that arrive by responding to them with a 200. 3. Subscribers may choose to reject zero or more of the NOTIFY requests that arrive by responding to them with a 481. 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I don't personally care which) accept exactly one NOTIFY message with a 200, and reject all others with a 481. 5. Subscribers _to_ _presence_ _information_ select which NOTIFY to accept based on the dialog information established by the 2xx response to the SUBSCRIBE. Moving forward, then, I see two sets of problems to be addressed: Forking SUBSCRIBE: - How do we perform authentication for forked SUBSCRIBE messages? This is actually a more general problem which can be phrased "How do we perform authentication for forked XXX messages?" where XXX includes INVITE. I would *really*, *really* like to see a more general solution to this problem before we start trying to cobble something together for SUBSCRIBE. - How do we protect against the DOS attacks that Robert describes? Presence: - In a forking situation, it is likely (probable, even) that the NOTIFY requests will arrive at the subscriber before the 2xx reply to the SUBSCRIBE. Does that mean that the response to the NOTIFY requests will be suppressed until the SUBSCRIBE request completes? If so, this should be well documented in the presence event package. - Some of the arguments made against accepting multiple dialogs created by a single SUBSCRIBE were privacy based: an aggregation point must exist in the network to provide a consistent policy. Given that there is no way to enforce that only one dialog is accepted, are there any privacy concerns that can arise from rogue clients accepting all received NOTIFYs? /a _______________________________________________ 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 Nov 21 15:31:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04431 for ; Wed, 21 Nov 2001 15:31:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALKTOhp020427; Wed, 21 Nov 2001 15:29:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12008; Wed, 21 Nov 2001 15:31:08 -0500 (EST) Received: from pine.il.neustar.com (pine.neustar.com [209.173.57.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11930 for ; Wed, 21 Nov 2001 15:17:20 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.il.neustar.com (8.11.0/8.11.0) with ESMTP id fALKGxJ31533 for ; Wed, 21 Nov 2001 14:16:59 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 14:19:23 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAC72@va02.va.neustar.com> From: "Peterson, Jon" To: "'simple@mailman.dynamicsoft.com'" Subject: FW: [Simple] I-D ACTION:draft-mankin-im-session-guide-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C172C9.CE92E190" 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, 21 Nov 2001 14:19:22 -0600 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_000_01C172C9.CE92E190 Content-Type: text/plain; charset="iso-8859-1" Just to briefly introduce this draft to the group, (Transport Area Director) Allison Mankin and I have prepared a few comments on the selection of a transport protocol for instant messaging, and some consequences of the introduction of intermediaries to IM streams, which are presented in this document. Also note that Allison has offered to give a presentation on these issues during the SIMPLE session in SLC next month. Jon Peterson NeuStar, Inc. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, November 21, 2001 3:59 AM Cc: simple@mailman.dynamicsoft.com Subject: [Simple] I-D ACTION:draft-mankin-im-session-guide-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for Instant Message Sessions Author(s) : A. Mankin, J. Peterson Filename : draft-mankin-im-session-guide-00.txt Pages : 14 Date : 20-Nov-01 This document recommends a set of guidelines for session-based instant messaging, focusing particularly on security properties, the selection of transport protocols and the effects of network intermediaries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mankin-im-session-guide-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mankin-im-session-guide-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mankin-im-session-guide-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C172C9.CE92E190 Content-Type: message/rfc822 To: Subject: Date: Wed, 21 Nov 2001 14:19:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C172C9.CE92E190" ------_=_NextPart_002_01C172C9.CE92E190 Content-Type: text/plain ------_=_NextPart_002_01C172C9.CE92E190 Content-Type: application/octet-stream; name="ATT16476" Content-Disposition: attachment; filename="ATT16476" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011120151609.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mankin-im-session-guide-00.txt ------_=_NextPart_002_01C172C9.CE92E190 Content-Type: message/external-body; site="internet-drafts"; dir="draft-mankin-im-session-guide-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C172C9.CE92E190-- ------_=_NextPart_000_01C172C9.CE92E190-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 15:59:55 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05584 for ; Wed, 21 Nov 2001 15:59:54 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALKvPhp020671; Wed, 21 Nov 2001 15:57:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12160; Wed, 21 Nov 2001 15:59:08 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12149 for ; Wed, 21 Nov 2001 15:58:18 -0500 (EST) Received: from dynamicsoft.com (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fALKtVs02858; Wed, 21 Nov 2001 14:55:31 -0600 Message-ID: <3BFC14C3.1010806@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011115 X-Accept-Language: en-us MIME-Version: 1.0 To: Theodore Havinis CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] RE: Buddy list per User per Event service association ??? 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, 21 Nov 2001 14:55:31 -0600 Content-Transfer-Encoding: 7bit Theodore Havinis wrote: > > Thanks, it helped. > So, I have a buddy list, with buddies who subscribed to > my call event, and my call event buddy list gets updated (through a watcher > client) about > my buddies presence, so I know who is available to be called and who isn't > because they > appear to be as offline. > Does that make sense ? > Actually, it does not. Your buddy list(s) are lists of people you subscribe to, not lists of people who subscribe to you. If you are talking about automatically generating recipricol subscriptions, where you subscribe to everyone who subscribes to you, then that is an application level problem, not a protocol one. Nothing prevents an application from automatically adding a user to your buddy list if you authorize them to subscribe to you. _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 16:51:09 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09545 for ; Wed, 21 Nov 2001 16:51:09 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALLkdhp020980; Wed, 21 Nov 2001 16:46:39 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12323; Wed, 21 Nov 2001 16:48:08 -0500 (EST) Received: from oe-mp2.bizmailsrvcs.net (oe-mp2pub.managedmail.com [206.46.164.23]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12312 for ; Wed, 21 Nov 2001 16:47:27 -0500 (EST) Received: from oe-ismta2.bizmailsrvcs.net ([206.46.164.27]) by oe-mp2.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20011121214602.GHCH22528.oe-mp2.bizmailsrvcs.net@oe-ismta2.bizmailsrvcs.net>; Wed, 21 Nov 2001 15:46:02 -0600 Received: from tharvinis ([206.35.147.89]) by oe-ismta2.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with SMTP id <20011121214458.TTQW13355.oe-ismta2.bizmailsrvcs.net@tharvinis>; Wed, 21 Nov 2001 15:44:58 -0600 From: "Theodore Havinis" To: "Ben Campbell" Cc: "Jonathan Rosenberg" , Subject: RE: [Simple] RE: Buddy list per User per Event service association ??? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3BFC14C3.1010806@dynamicsoft.com> 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, 21 Nov 2001 13:51:27 -0800 Content-Transfer-Encoding: 7bit Hi Ben, Pls find my comments below. Thanks /Theo >-----Original Message----- >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >Sent: Wednesday, November 21, 2001 12:56 PM >To: Theodore Havinis >Cc: Jonathan Rosenberg; simple@mailman.dynamicsoft.com >Subject: Re: [Simple] RE: Buddy list per User per Event service >association ??? > > > > >Theodore Havinis wrote: > > > > >> >> Thanks, it helped. >> So, I have a buddy list, with buddies who subscribed to >> my call event, and my call event buddy list gets updated >(through a watcher >> client) about >> my buddies presence, so I know who is available to be called and >who isn't >> because they >> appear to be as offline. >> Does that make sense ? >> > >Actually, it does not. Your buddy list(s) are lists of people you >subscribe to, not lists of people who subscribe to you. It coulbe be a matter of definition, but I also see as buddies of mine anyone who wants to SUBSCRIBE to me and I authorize him/her. If you are >talking about automatically generating recipricol subscriptions, where >you subscribe to everyone who subscribes to you, then that is an >application level problem, not a protocol one. Not necessarily generating reciprocal subscriptions. I agree this is an application issue. Nothing prevents an >application from automatically adding a user to your buddy list if you >authorize them to subscribe to you. So here is the issue, and maybe its only a definition issue. While in your first statement you say that my buddy list consists of people that I subscribe to, in your last statement you say that its also possible for somebody to join my buddy list provided I authorize his SUBSCRIBE request. So the application is the entity which will decide if the person that wants to SUBSCRIBE to me is placed in the same buddy list with the persons that I have subscribed to. But in principle, both the ones that I SUBSCRIBE to and the ones I authorize to SUBSCRIBE to me are buddies of mine and the key reason for that is "authorization" as I see it. So, in my view it works both ways, and that can be used by an application on my behalf for building up say a buddy list consisting of people who accept my calls when I call them, and a buddy list of the people that I allow them to call me. These two lists can be combined to one such "call service-buddy list" or can be kept separate such as 'incoming call service buddy list' and 'outgoing call service buddy list'. Theo _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 21 17:11:22 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10875 for ; Wed, 21 Nov 2001 17:11:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fALM5Mhp021138; Wed, 21 Nov 2001 17:05:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12404; Wed, 21 Nov 2001 17:07:08 -0500 (EST) 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 RAA12393 for ; Wed, 21 Nov 2001 17:06:10 -0500 (EST) 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 fALM4Nhp021129 for ; Wed, 21 Nov 2001 17:04:23 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Nov 2001 17:05:48 -0500 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] updated presence I-D 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, 21 Nov 2001 17:05:47 -0500 Folks, I just submitted an update to the presence spec based on the various discussions on the list during last call. You can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-simple-presence-04.txt This may or may not appear in the archives; for some reason the submission bounced as being after the deadline, even though the bounced mail had a time of around 4:45. Changes documented in the changes section. Since our discussions more or less went full circle to arrive back where we had started with respect to multiple PA, the scope of the changes is not so large. The few remaining open issues are primarily sip-events issues (how to represent subscription state, how to handle 200/NOTIFY race condition). So, I am not aware of any presence specific issues, excepting perhaps a few more specific security recommendations than is in the doc. Thanks, 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 Thu Nov 22 05:54:33 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12471 for ; Thu, 22 Nov 2001 05:54:32 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAMApShp022615; Thu, 22 Nov 2001 05:51:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14723; Thu, 22 Nov 2001 05:53:09 -0500 (EST) Received: from zander.antihe.ro (dsl231-037-205.sea1.dsl.speakeasy.net [216.231.37.205]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id FAA14712 for ; Thu, 22 Nov 2001 05:52:17 -0500 (EST) Received: (qmail 7198 invoked by uid 1002); 22 Nov 2001 10:51:54 -0000 From: Torrey Searle To: simple@mailman.dynamicsoft.com Message-ID: <20011122025154.A7172@antihe.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Simple] question on presence callflow 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, 22 Nov 2001 02:51:54 -0800 In the callflow example 8.2 of the presence document 04, there is a call flow for the presentity changing state, however there are afew strange things about it 1. the presentity state doesn't change, it both notifies indicate the state as open/available 2. upon the state change, the PUA sends a register to the PA, persumably to update it's presence info using the REGISTER method, however, aside from stating support for SUBSCRIBE (which it also did in the inital invite) there is no presence state information contained in the register) I notice that in older versions on the draft, this example used to show a transition from open/available to closed/busy and the register updating the presence info using the description parameter defined in the caller preferences extension, since section 6.2 of the 04 presence document still recommends the use of the caller preferences extension to update state of the presentity, why was this parameter dropped from the current call flow? Does this call flow still make sense in the current version of the draft? Can it be updated to show an actual change of state? Torrey _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 22 05:59:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12525 for ; Thu, 22 Nov 2001 05:59:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAMAuMhp022680; Thu, 22 Nov 2001 05:56:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14758; Thu, 22 Nov 2001 05:58:08 -0500 (EST) Received: from eins.siemens.at (eins.siemens.at [193.81.246.11]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14736 for ; Thu, 22 Nov 2001 05:55:59 -0500 (EST) Received: from scesie13.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at with ESMTP id fAMAtZT13614; Thu, 22 Nov 2001 11:55:35 +0100 Received: (from smap@localhost) by scesie13.sie.siemens.at (8.9.3/8.9.3) id LAA25459; Thu, 22 Nov 2001 11:55:34 +0100 (MET) Received: from atws15tc.sie.siemens.at(158.226.135.41) by scesie13 via smap (V2.0beta) id xma023204; Thu, 22 Nov 01 11:54:05 +0100 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Thu, 22 Nov 2001 11:54:01 +0100 Message-ID: From: Brazier Lachlan To: "'Jonathan Rosenberg '" , "''Brian Stucker' '" , "'adam.roach '" , "'simple '" Subject: AW: [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: Thu, 22 Nov 2001 11:53:59 +0100 Hello, no objections against these solutions. Anyway my first guess would have been to send 1xx responses to he NOTIFY, until the resposne to the SUBSCRIBE arrives. There's no need for an additional SUBSCRIBE then, for which I need to keep the routing path established by the NOTIFY. Comments Lachlan how about this: 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it accepts the NOTIFY 2. once the response to the SUBSCRIBE comes, if its not a match for the NOTIFY, the subscriber refreshes the dialog associated with the NOTIFY, but with Expires:0, to terminate it. This avoids the tight transaction timing interdependencies at the expense of some additional higher level processing. BTW, this is really a sip-events issue not so much a simple issue. -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: Wednesday, November 21, 2001 2:23 PM To: adam.roach; simple Subject: RE: [Simple] 200 vs. 202 You bring up an important point about the watcher having to wait for the response to the SUBSCRIBE before processing the NOTIFY. This could give us problems if the 200 takes a long time getting back to the watcher, and the NOTIFY, in the meantime, is just sitting there being retransmitted over and over, waiting for a response. Depending on the T1 and T2 timers being used, this could create a race condition that might cause a subscription to fail because there was no response to the immediate NOTIFY. In general, what happens when a NOTIFY to the inital SUBSCRIBE fails to be acknowledged? Does the subscription go away like it does for later NOTIFY messages? The reason I ask, is because it would seem to leave the watcher in an undefined state. What are the responsibilities of a watcher that sends a SUBSCRIBE, gets a 200, and then no NOTIFY? A possible solution would be to silently throw away and NOTIFY messages that we have not gotten a response (200) on the request to create a dialogue for (the SUBSCRIBE). If we do that, then we could wait for some period of time (say the expires header in the 200 response). If that period of time elapses without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). Thoughts? Brian -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Tuesday, November 20, 2001 3:18 PM To: simple Subject: RE: [Simple] 200 vs. 202 While I disagree with Brian and Jonathan about the problems presented by having multiple PAs in the network, I am willing to quit the topic for the sake of moving forward. I am very wary, however, of any discussions which use arguments about the general case of forking of SUBSCRIBE requests instead of those involving multiple PAs. I wouldn't have even entered the fray if the arguments presented by several parties didn't attack the very notion of SUBSCRIBE forking (instead of limiting themselves to presence in particular). So, with my capitulation, I'll attempt to enumerate what I think we've all agreed on: 1. SUBSCRIBE requests may fork. 2. Subscribers may choose to accept zero or more of the NOTIFY requests that arrive by responding to them with a 200. 3. Subscribers may choose to reject zero or more of the NOTIFY requests that arrive by responding to them with a 481. 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I don't personally care which) accept exactly one NOTIFY message with a 200, and reject all others with a 481. 5. Subscribers _to_ _presence_ _information_ select which NOTIFY to accept based on the dialog information established by the 2xx response to the SUBSCRIBE. Moving forward, then, I see two sets of problems to be addressed: Forking SUBSCRIBE: - How do we perform authentication for forked SUBSCRIBE messages? This is actually a more general problem which can be phrased "How do we perform authentication for forked XXX messages?" where XXX includes INVITE. I would *really*, *really* like to see a more general solution to this problem before we start trying to cobble something together for SUBSCRIBE. - How do we protect against the DOS attacks that Robert describes? Presence: - In a forking situation, it is likely (probable, even) that the NOTIFY requests will arrive at the subscriber before the 2xx reply to the SUBSCRIBE. Does that mean that the response to the NOTIFY requests will be suppressed until the SUBSCRIBE request completes? If so, this should be well documented in the presence event package. - Some of the arguments made against accepting multiple dialogs created by a single SUBSCRIBE were privacy based: an aggregation point must exist in the network to provide a consistent policy. Given that there is no way to enforce that only one dialog is accepted, are there any privacy concerns that can arise from rogue clients accepting all received NOTIFYs? /a _______________________________________________ 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 Thu Nov 22 06:09:12 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12645 for ; Thu, 22 Nov 2001 06:09:12 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAMB6Nhp022754; Thu, 22 Nov 2001 06:06:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14808; Thu, 22 Nov 2001 06:08:08 -0500 (EST) Received: from zander.antihe.ro (dsl231-037-205.sea1.dsl.speakeasy.net [216.231.37.205]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id GAA14797 for ; Thu, 22 Nov 2001 06:07:37 -0500 (EST) Received: (qmail 7702 invoked by uid 1002); 22 Nov 2001 11:07:15 -0000 From: Torrey Searle To: simple@mailman.dynamicsoft.com Message-ID: <20011122030715.B7172@antihe.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Simple] CPIM and Presence 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, 22 Nov 2001 03:07:15 -0800 In the 01 version of the CPIM draft, it appears to indicate that the presentity element is a required element of the presence element, however the call flows in the Presence RFC omit this element, should this element be added in future versions of the Draft? Also in the Presence call flows, an element called detail appears in the status element to indicate im status, however it appears to be the same as the value element in the CPIM draft, the only difference being that the type paraleter has a value of "urn:ietf:params:cpim-presence:status-type:im" can the presence draft be updated to match? Torrey _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 23 05:19:19 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16197 for ; Fri, 23 Nov 2001 05:19:19 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fANAGXhp024482; Fri, 23 Nov 2001 05:16:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19033; Fri, 23 Nov 2001 05:18:09 -0500 (EST) Received: from mailrelay.bluelabs.se (mailrelay.bluelabs.se [194.17.38.34]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id FAA19022 for ; Fri, 23 Nov 2001 05:17:20 -0500 (EST) From: Hakan.Jonsson@bluelabs.se Received: from blnet-sth-vscan.bluelabs.se (blnet-sth-vscan1.bluelabs.se [194.17.38.247]) by mailrelay.bluelabs.se (Postfix) with SMTP id 0761117C6 for ; Fri, 23 Nov 2001 11:16:55 +0100 (CET) Received: FROM blue-sth1.bluelabs.se BY blnet-sth-vscan.bluelabs.se ; Fri Nov 23 11:16:54 2001 +0100 Subject: RE: [Simple] new I-D on subscribing to buddy lists To: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: X-MIMETrack: Serialize by Router on Blue-sth1/srv/Bluelabs(Release 5.0.6a |January 17, 2001) at 2001-11-23 11:16:54 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id FAA19022 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, 23 Nov 2001 11:16:54 +0100 Content-Transfer-Encoding: 8bit Some questions: - Why does the buddylist have a SIP URI of its own? A server supporting the buddylist package has enough information in the from header to perform its task. A PUA and a PA communicates without having to adress the PA specifically. - I think it should be possible to see that the buddylist event package is a delegated presence subscription event package, by making it a subpackage (or perhaps a superpackage), e.g. presence.buddylist (or buddylist.presence). I should be possible to perform delegated subscriptions to other event packages e.g. buddylist.myeventpackagename. The word buddylist would then not be very useful in itself; presence.delegate is my suggestion. The latter could perhaps be used in some way to join subscriptions. Say that I have made a SUBCRIBE request for the presence.delegate package and later make a SUBSCRIBE request for an individual user, it would be very useful to join the individual subscription to the delegated subscription. I am not sure how though (yet). Regards, Håkan Jonsson _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 23 10:03:14 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18284 for ; Fri, 23 Nov 2001 10:03:14 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fANF0Php024970; Fri, 23 Nov 2001 10:00:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19902; Fri, 23 Nov 2001 10:02:09 -0500 (EST) Received: from oe-mp1.bizmailsrvcs.net (oe-mp1pub.managedmail.com [206.46.164.22]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19891 for ; Fri, 23 Nov 2001 10:01:26 -0500 (EST) Received: from oe-ismta1.bizmailsrvcs.net ([206.46.164.26]) by oe-mp1.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with ESMTP id <20011123145820.BZQ6924.oe-mp1.bizmailsrvcs.net@oe-ismta1.bizmailsrvcs.net>; Fri, 23 Nov 2001 08:58:20 -0600 Received: from tharvinis ([206.35.147.89]) by oe-ismta1.bizmailsrvcs.net (InterMail vM.5.01.03.13 201-253-122-118-113-20010918) with SMTP id <20011123150057.FPPR27442.oe-ismta1.bizmailsrvcs.net@tharvinis>; Fri, 23 Nov 2001 09:00:57 -0600 From: "Theodore Havinis" To: "Rosen, Brian" Cc: Subject: RE: [Simple] RE: Buddy list per User per Event service association ??? 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 V6.00.2600.0000 In-Reply-To: <313680C9A886D511A06000204840E1CF57C578@whq-msgusr-02.pit.comms.marconi.com> 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, 23 Nov 2001 07:05:29 -0800 Content-Transfer-Encoding: 7bit I find it confusing taklking about buddies "one way only". I think whether I join a buddy list or I allow somebody to join my buddy list, if the application decides to put the 2 together, as far as i see it is part of the same buddy list. The determining factor should not be who initiates the SUBSCRIBE, but it should the 'authorization'. Theodore >-----Original Message----- >From: simple-admin@mailman.dynamicsoft.com >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Rosen, Brian >Sent: Wednesday, November 21, 2001 10:38 AM >To: 'Theodore Havinis' >Cc: 'simple@mailman.dynamicsoft.com' >Subject: RE: [Simple] RE: Buddy list per User per Event service >association ??? > > >And, it's a race to see who types the fastest..... > >The guy with the buddy list is John, not Bob. John has a list >of buddies he sees presence for. If he wants to add Bob to his >list, then he has to subscribe to Bob's presence, and indeed, >Bob can decide to not let him do that. > >The point of the buddy list is when John logs on for the >umpteenth time, instead of again subscribing to John, and Mary, >and Fred, and Joe individually, he does one operation (subscribe >my buddy list), and all the individual subscription actions >are performed on John's behalf. If any of them failed, that >"buddy" would not show presence to John. > >Bob may have his own buddy list, but it has the people Bob wants >to see presence for. > >So buddy lists are for watchers. Presentities may have lists of >authorized subscribers, or they may have more complex rules. So >far, that is beyond our specification work. AFAIK, a buddy list >is really just a shorthand equivalent to a bunch of individual >subscriptions. As Jonathan notes, this duplicates what is in AIM >or other commercial IM systems. In those systems, each of the >buddy lists are watchers. Of course, nothing prevents Bob from >being in John's buddy list, but that is up to John. It is up to >Bob to decide if he will let John see his presence information, >or, more precisely, what he will let him see, since it isn't binary. > >Brian > >> -----Original Message----- >> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] >> Sent: Wednesday, November 21, 2001 11:44 AM >> To: Jonathan Rosenberg >> Cc: simple@mailman.dynamicsoft.com >> Subject: RE: [Simple] RE: Buddy list per User per Event service >> association ??? >> >> >> >> Hi Jonathan, >> >> Thanks for your comments. >> >> Please find my comments below. >> >> Kind Rgds >> Theo >> >> >-----Original Message----- >> >From: simple-admin@mailman.dynamicsoft.com >> >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan >> >Rosenberg >> >Sent: Tuesday, November 20, 2001 10:48 PM >> >To: 'Theodore Havinis'; Jonathan Rosenberg >> >Cc: simple@mailman.dynamicsoft.com >> >Subject: [Simple] RE: Buddy list per User per Event service >> association >> >??? >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] >> >> Sent: Tuesday, November 20, 2001 5:38 PM >> >> To: Jonathan Rosenberg >> >> Cc: simple@mailman.dynamicsoft.com >> >> Subject: Buddy list per User per Event service association ??? >> >> >> >> I have two questions for clarifications. I'd appreciate >> your feedback. >> >> >> >> Clarification-I: Is it possible with the model you >> describe to build a >> >> buddy-list tree >> >> whereby each User has separate buddy lists for separate services ie >> >> effectively a buddy list >> >> for telephony buddies (ie buddies who want to subscribe to >> >> his telephony >> >> event), a separate >> >> one for IM buddies, or even distinguish between a buddy list >> >> for 'business >> >> telephony >> >> buddies' and a buddy list for 'family telephony buddies'. >> > >> >Of course. A buddy list is just a named resource. I can >> subscribe to any >> >named resource - sip:friends@foo.com, sip:family@foo.com, >> etc., so long as >> >those resources are defined. >> > >> >> >> >> Example: A user gets a subscription from an operator for >> >> telephony service, >> >> IM service, Voice Mail service etc. >> >> and he would like to build the following scenario that >> reach him via >> >> telephony you should become part of his >> >> telephony-buddies, for as long as needed ie just for the >> >> duration of the >> >> call or longer. >> >> >> >> >> >> IM event Telephony event >> >> VoiceMail >> >> event >> >> |-----------| |--------------|------------| >> >> |---------------| >> >> | | | | | | >> >> | >> >> fam.BLSS buz.BLSS fam.BLSS friend.BLSS buz.BLSS >> >> friends.BLSS buz.BLSS >> >> >> >> The sum of BLSS's is the User's BLSS which resides with his >> >> home operator or >> >> 3rd party-provider. >> > >> >I'm afraid you've lost me here. Just to be clear we are >> talking about the >> >same thing - my buddy list is the set of people I want to >> learn presence >> >about. In existing systems, this is the list of names you >> see on your own >> >messenger tool. Rather than subscribing to each one >> individually, I can >> >subscribe to sip:mybuddies@foo.com, and the server handling >> >mybuddies@foo.com generates subscriptions for all the users >> in my list. >> >> I didn't mean it differently. >> > >> >> So what I was trying to understand is 'where we going' when combining >> Events, Buddy Lists, >> Wacher lists since these drafts can be very powerful in some ways when >> combined. >> >> So here is an example of what I was trying to say in my >> previous email. >> >> Lets assume that John decides to call Bob for the first time. >> One way to provide certain screening services on behalf of >> Bob for the call >> he is receiving from John >> is to have John first SUBSCRIBE to the Bob's authorized buddy >> list for the >> telephony event. >> So, as soon as John tries to SUBSCRIBE to Bob's "call event >> buddy list" >> Bob gets notified that John wants to SUBSCRIBE to him. Bob >> has a number of >> choices: >> (a) reject the subscription >> (b) allow John to talk to Bob without allowing him joining >> Bob's call event >> buddy list >> (c) allow Jonh to talk to Bob, and at the same time, let him >> join Bob's call >> event buddy list >> >> If Bob allows the subscription of John to his telephony >> event, then John >> joins Bob's >> buddy list for telephony. Next time John calls Bob, John is >> already a buddy >> of his >> for the telephony event, thus getting authorized and the call gets >> established (assuming no other restrictions) >> >> What I describe above for the call event, can be applied to any >> communication mean such as IM etc. >> >> I was wondering if this one way of how we envision to make >> use of Events, >> Buddy lists in future in order >> to give more control to a Callee's communication. >> >> >> >> >> >> So, is that possible to be done when combining buddy-lists, >> >> events etc. >> >> based on the buddy-list draft and on the >> >> event draft from Adam R. and also should all these events and >> >> buddy lists be >> >> registered with IANA ??? >> > >> >You wouldn't IANA register buddy lists any more than you would >> >IANA register >> >user names. >> > >> >> >> >> Clarification-II: >> >> I believe it would be good if you could explain the >> >> connection between the >> >> 'watcherinfo' draft and this draft. >> >> In my understanding with the watcherinfo one can start >> >> creating buddy lists >> >> as well, ie allow those watchers requesting >> >> my presence information to subscribe to my presence. >> > >> >They are basically comverses of each other: >> > >> >A buddy list is the set of people I want to subscribe to >> (i.e., the set of >> >people whose presence I want to learn) >> > >> >The watcher list is the set of people who want to subscribe >> to me (which >> >includes those that have successfully subscribed and those >> who are merely >> >pending). >> > >> >Both are lists, but represent different entities. A buddy >> list benefits a >> >subscriber, a watcher list is for a presentity. >> > >> >I can set up authorization policy as a list that contains >> those folks that >> >are allowed to subscribe to me. Call this the "authorized >> watcher list". It >> >may so happen that my authorized watcher list is the same as >> my buddy list, >> >but that is not necessary; these are fundamentally different lists >> >as far as >> >the protocol/architecture is concerned. >> >> >> They may be the same for a >> >particular deployment of a real service, but thats a separate matter. >> >> Thanks, it helped. >> So, I have a buddy list, with buddies who subscribed to >> my call event, and my call event buddy list gets updated >> (through a watcher >> client) about >> my buddies presence, so I know who is available to be called >> and who isn't >> because they >> appear to be as offline. >> Does that make sense ? >> >> >> Thanks >> /Theo >> >> > >> >-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 >> >_______________________________________________ >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 Mon Nov 26 03:18:47 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17565 for ; Mon, 26 Nov 2001 03:18:47 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQ8FUhp029182; Mon, 26 Nov 2001 03:15:30 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01578; Mon, 26 Nov 2001 03:17:09 -0500 (EST) 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 DAA01565 for ; Mon, 26 Nov 2001 03:16:49 -0500 (EST) 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 CAA25095 for ; Mon, 26 Nov 2001 02:16:25 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 26 Nov 2001 02:09:04 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 02:14:55 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE78B7A@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Christian Huitema , Michael Hammer , Jonathan Rosenberg Cc: adam.roach@ericsson.com, simple , "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17652.72765CC0" 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: Mon, 26 Nov 2001 02:15:02 -0600 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_01C17652.72765CC0 Content-Type: text/plain; charset="iso-8859-1" That's what I was afraid of. TCP is incredibly expensive to use for presence notification, in my mind, because the connection has to be baby-sitted for extremely long periods of time to keep any potential pinholes open in case a notify needs to be sent. That's bad. I know there are tons of web servers out there that use TCP all the time, with no problem, but they don't have to keep that connection up for very long. A flash in the pan compared to what presence would do. Hmmm.... Brian -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, November 23, 2001 11:38 PM To: Michael Hammer; Jonathan Rosenberg Cc: adam.roach@ericsson.com; Stucker, Brian [NGB:B635:EXCH]; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. I hope you are all aware that sending long messages over UDP is a *really bad idea*. The failure mode is the following: 1) long message gets fragmented in a set of path-MTU sized IP messages; 2) at least one message in the set is dropped in the network; 3) application times out and resend long message; 4) repeat step one. The theory says that transmissions of independent messages should result in at least one transmission of the whole set eventually, but the independent error assumption is false in practice. There are error situations in which every fourth or fifth message gets dropped, in which case no amount of repetition solves the problem. This is not theoretical: I have seen the problem occur for example in IKE, with UDP messages containing long certificate chains. My rule of thumb is that trying to transmit UDP messages longer than 4K is guaranteed to fail spectacularly in at least some circumstances, and that only messages shorter than the IPv6 guaranteed minimal MTU are safe -- that is, about 1K in the payload. The practical options are, only use short presence documents, or use TCP. -- Christian Huitema > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 7:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; Patrick > Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does this preclude > any implementation (higher level application using SIP) from choosing to > send the body of the Notifies as incremental parts? It would seem that > the > SIP-level mechanisms would be unaware of the full nature of the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a mechanism. > > Mike > > > At 01:58 AM 11/21/2001 -0500, Jonathan Rosenberg wrote: > >I agree with Adam that defining a SIP specific fragmentation is a bad > thing. > >We have discussed this on the SIP list and it has been quickly squashed. > > > >For simple, a real delta versioning solution is the best thing. > > > >Another solution is TCP, which is generally better as far as firewall/nat > >traversal is concerned, not worse, and has none of these fragmentation > >issues. > > > >-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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Tuesday, November 20, 2001 6:50 PM > > > To: 'Brian Stucker'; simple > > > Cc: Alex Nava; Patrick Sollee; Sanjoy Sen > > > Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. > > > > > > > > > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > > > > > > > >Ok, you've really got me confused now. I even went off to > > > RFC-0760 (IP) and > > > >RFC-0768 (UDP) to make sure that I wasn't off in the weeds. > > > Even bis-05 SIP > > > talks > > > >about MTU problems. > > > > > > It makes a recommendation. If fragmentation were really a > > > problem, SIP would > > > mandate behavior. As it is, it's just trying to raise > > > awareness of some of > > > the related issues (like the two I discuss in a previous mail). > > > > > > >I don't think I'm off in the weeds, but I see what you're > > > referring to. > > > >I now see what you're getting at with the 64k size (maximum > > > datagram size), > > > but > > > >since IP makes no guarantee that any particular packet reaches it's > > > destination, it's > > > >really IP that is the problem. I see what you're getting at > > > with the UDP > > > packet > > > >being fragmented to the IP next-hop MTU size, but that means > > > that portions of > > > the UDP > > > >packet may go missing and unknown since IP doesn't do > > > anything to ensure that > > > any > > > >particular datagram makes it to the destination. > > > > > > That's a problem even when you don't exceed the MTU. That's why > > > SIP retransmits requests. > > > > > > There's a timer for reconstitution of the packet, sequence numbers, > > > a checksum, and all sorts of goodies in the UDP fragmentation to make > > > sure that it works. It's unreliable (but in an all-or-nothing sort > > > of way, just like all UDP datagram transmissions) but it works. All > > > you need is a mechanism to retransmit datagrams until they are > > > acknowledged, and SIP provides such a mechanism. > > > > > > >What's worse, is popular operating systems such as Microsoft Windows > > > >(with the possible exception of XP) specifically drops any datagram > > > >exceeding the MTU value until it receives an ARP response > > > for the first > > > >datagram (thus guaranteeing it to drop all of the portions of the UDP > > > >packet, except for the very last one: > > > >http://support.microsoft.com/support/kb/articles/q233/4/01.asp). > > > > > > I have two reactions to this: > > > > > > 1. Are you *seriously* proposing that we add provisions in the > > > protocol to work around Microsoft's buggy IP implementation? > > > > > > 2. Even with this special little Microsoft bug, it all works. > > > The first transmission of a UDP packet to a host might get > > > lost; however, this first transmission will load the ARP cache > > > for the destination, and the subsequent retransmissions will > > > progress as normal. > > > > > > I'm not arguing against your solution. I'm pointing out that > > > the "problem" you are trying to solve is not a problem. It might > > > be an inconvenience in corner cases, but it's not a problem. > > > > > > /a > > > > > > _______________________________________________ > > > 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 ------_=_NextPart_001_01C17652.72765CC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: Question regarding NOTIFY messages using = UDP.

That's what I was afraid of.

TCP is incredibly expensive to use for presence = notification, in my mind, because the connection has to be baby-sitted = for extremely long periods of time to keep any potential pinholes open = in case a notify needs to be sent. That's bad. I know there are tons of = web servers out there that use TCP all the time, with no problem, but = they don't have to keep that connection up for very long. A flash in = the pan compared to what presence would do.

Hmmm....

Brian




-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Friday, November 23, 2001 11:38 PM
To: Michael Hammer; Jonathan Rosenberg
Cc: adam.roach@ericsson.com; Stucker, Brian = [NGB:B635:EXCH]; simple;
Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick = [NGC:B680:EXCH]; Sen, Sanjoy
[NGB:B692:EXCH]
Subject: RE: [Simple] RE: Question regarding NOTIFY = messages using UDP.


I hope you are all aware that sending long messages = over UDP is a
*really bad idea*. The failure mode is the = following:
 1) long message gets fragmented in a set of = path-MTU sized IP messages;

 2) at least one message in the set is dropped = in the network;
 3) application times out and resend long = message;
 4) repeat step one.
The theory says that transmissions of independent = messages should result
in at least one transmission of the whole set = eventually, but the
independent error assumption is false in practice. = There are error
situations in which every fourth or fifth message = gets dropped, in which
case no amount of repetition solves the problem. = This is not
theoretical: I have seen the problem occur for = example in IKE, with UDP
messages containing long certificate chains.

My rule of thumb is that trying to transmit UDP = messages longer than 4K
is guaranteed to fail spectacularly in at least some = circumstances, and
that only messages shorter than the IPv6 guaranteed = minimal MTU are safe
-- that is, about 1K in the payload.

The practical options are, only use short presence = documents, or use
TCP.

-- Christian Huitema

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Wednesday, November 21, 2001 7:11 = AM
> To: Jonathan Rosenberg
> Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; = simple; Alex Nava;
Patrick
> Sollee; Sanjoy Sen
> Subject: RE: [Simple] RE: Question regarding = NOTIFY messages using
UDP.
>
> Jonathan,
>
> While not favoring any fragmentation mechanism = for SIP, does this
preclude
> any implementation (higher level application = using SIP) from choosing
to
> send the body of the Notifies as incremental = parts?  It would seem
that
> the
> SIP-level mechanisms would be unaware of the = full nature of the body
which
> it carries and should place no restrictions on = that body.
>
> That is, it provides no mechanism nor precludes = use of such a
mechanism.
>
> Mike
>
>
> At 01:58 AM 11/21/2001 -0500, Jonathan = Rosenberg wrote:
> >I agree with Adam that defining a SIP = specific fragmentation is a bad
> thing.
> >We have discussed this on the SIP list and = it has been quickly
squashed.
> >
> >For simple, a real delta versioning = solution is the best thing.
> >
> >Another solution is TCP, which is generally = better as far as
firewall/nat
> >traversal is concerned, not worse, and has = none of these
fragmentation
> >issues.
> >
> >-Jonathan R.
> >
> >---
> >Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> >Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = >dynamicsoft         &nb= sp;           &nb= sp;           East = Hanover, NJ 07936
> = >jdrosen@dynamicsoft.com       &nb= sp;           &nb= sp; FAX:   (973) 952-5050
> >http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >
> > > -----Original Message-----
> > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > > Sent: Tuesday, November 20, 2001 6:50 = PM
> > > To: 'Brian Stucker'; simple
> > > Cc: Alex Nava; Patrick Sollee; Sanjoy = Sen
> > > Subject: [Simple] RE: Question = regarding NOTIFY messages using
UDP.
> > >
> > >
> > > >From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
> > > >
> > > >Ok, you've really got me confused = now. I even went off to
> > > RFC-0760 (IP) and
> > > >RFC-0768 (UDP) to make sure that = I wasn't off in the weeds.
> > > Even bis-05 SIP
> > > talks
> > > >about MTU problems.
> > >
> > > It makes a recommendation. If = fragmentation were really a
> > > problem, SIP would
> > > mandate behavior. As it is, it's just = trying to raise
> > > awareness of some of
> > > the related issues (like the two I = discuss in a previous mail).
> > >
> > > >I don't think I'm off in the = weeds, but I see what you're
> > > referring to.
> > > >I now see what you're getting at = with the 64k size (maximum
> > > datagram size),
> > > but
> > > >since IP makes no guarantee that = any particular packet reaches
it's
> > > destination, it's
> > > >really IP that is the problem. I = see what you're getting at
> > > with the UDP
> > > packet
> > > >being fragmented to the IP = next-hop MTU size, but that means
> > > that portions of
> > > the UDP
> > > >packet may go missing and unknown = since IP doesn't do
> > > anything to ensure that
> > > any
> > > >particular datagram makes it to = the destination.
> > >
> > > That's a problem even when you don't = exceed the MTU. That's why
> > > SIP retransmits requests.
> > >
> > > There's a timer for reconstitution of = the packet, sequence
numbers,
> > > a checksum, and all sorts of goodies = in the UDP fragmentation to
make
> > > sure that it works. It's unreliable = (but in an all-or-nothing sort
> > > of way, just like all UDP datagram = transmissions) but it works.
All
> > > you need is a mechanism to retransmit = datagrams until they are
> > > acknowledged, and SIP provides such a = mechanism.
> > >
> > > >What's worse, is popular = operating systems such as Microsoft
Windows
> > > >(with the possible exception of = XP) specifically drops any
datagram
> > > >exceeding the MTU value until it = receives an ARP response
> > > for the first
> > > >datagram (thus guaranteeing it to = drop all of the portions of the
UDP
> > > >packet, except for the very last = one:
> > > >http://support.microsoft.com/support/kb/articles/q233/= 4/01.asp).
> > >
> > > I have two reactions to this:
> > >
> > > 1. Are you *seriously* proposing that = we add provisions in the
> > >    protocol to work = around Microsoft's buggy IP implementation?
> > >
> > > 2. Even with this special little = Microsoft bug, it all works.
> > >    The first = transmission of a UDP packet to a host might get
> > >    lost; however, this = first transmission will load the ARP cache
> > >    for the = destination, and the subsequent retransmissions will
> > >    progress as = normal.
> > >
> > > I'm not arguing against your = solution. I'm pointing out that
> > > the "problem" you are = trying to solve is not a problem. It might
> > > be an inconvenience in corner cases, = but it's not a problem.
> > >
> > > /a
> > >
> > > = _______________________________________________
> > > 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=

------_=_NextPart_001_01C17652.72765CC0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 04:08:17 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17842 for ; Mon, 26 Nov 2001 04:08:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQ95N7x000251; Mon, 26 Nov 2001 04:05:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00208; Mon, 26 Nov 2001 04:07:10 -0500 (EST) 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 EAA00193 for ; Mon, 26 Nov 2001 04:05:46 -0500 (EST) 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 DAA00232 for ; Mon, 26 Nov 2001 03:05:22 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Mon, 26 Nov 2001 03:00:54 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 03:04:12 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EE78B81@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "Brian Stucker" , Christian Huitema , Michael Hammer , Jonathan Rosenberg Cc: adam.roach@ericsson.com, simple , "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17659.5582FFE0" 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, 26 Nov 2001 03:04:20 -0600 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_01C17659.5582FFE0 Content-Type: text/plain; charset="iso-8859-1" Ok, here's a thought... If we're in a position where we think we're going to need to use TCP (or some other connection-oriented protocol) to notify the watcher (in this example, a presence subscriber), but it's difficult to keep up a bunch of TCP connections, we use the following general mechanism. 1. We send the watcher a NOTIFY that says in effect "you need to fetch the current state of this resource" (in this case, probably using UDP). 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. 3. The watcher sends a SUBSCRIBE in to fetch the current state of the resource (in this case a presentity) using the transport of it's choosing. If it knows it's behind a firewall, or a NAT, then it can pick TCP, for instance. 4. The presence agent responds to the SUBSCRIBE with a 200 OK (because there shouldn't be any issues about authorization or not). 5. The presence agent sends a NOTIFY to the watcher using the same transport, IP, port, everything, that the fetch SUBSCRIBE was received with. Simple as that. We trigger a TCP connection inbound from the client using a UDP message. NAT or not, it saves on having to nail up a bunch of TCP connections for a long period of time, and it's super easy to implement. Events draft change: All we'd need to change is to either add a new reason to the subscription-expires header, like "stale" with a non-zero value, and add a restriction that the state agent MUST respond to a fetch using the same transport parameters used by the watcher from the SUBSCRIBE. -OR- Events draft/watcherinfo change: We add a new event to the watcherinfo format called "stale" to the current list (subscribe, rejected, approved, ...), and recommend that when a watcher to eventpkg.winfo receives this event, they should perform a fetch. Then we add the change to the events draft that when a fetch is performed, the source parameters from the SUBSCRIBE should be used to send the NOTIFY. Thoughts? Brian Stucker -----Original Message----- From: Stucker, Brian [NGB:B635:EXCH] Sent: Monday, November 26, 2001 2:15 AM To: Christian Huitema; Michael Hammer; Jonathan Rosenberg Cc: adam.roach@ericsson.com; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. That's what I was afraid of. TCP is incredibly expensive to use for presence notification, in my mind, because the connection has to be baby-sitted for extremely long periods of time to keep any potential pinholes open in case a notify needs to be sent. That's bad. I know there are tons of web servers out there that use TCP all the time, with no problem, but they don't have to keep that connection up for very long. A flash in the pan compared to what presence would do. Hmmm.... Brian -----Original Message----- From: Christian Huitema [mailto:huitema@windows.microsoft.com] Sent: Friday, November 23, 2001 11:38 PM To: Michael Hammer; Jonathan Rosenberg Cc: adam.roach@ericsson.com; Stucker, Brian [NGB:B635:EXCH]; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. I hope you are all aware that sending long messages over UDP is a *really bad idea*. The failure mode is the following: 1) long message gets fragmented in a set of path-MTU sized IP messages; 2) at least one message in the set is dropped in the network; 3) application times out and resend long message; 4) repeat step one. The theory says that transmissions of independent messages should result in at least one transmission of the whole set eventually, but the independent error assumption is false in practice. There are error situations in which every fourth or fifth message gets dropped, in which case no amount of repetition solves the problem. This is not theoretical: I have seen the problem occur for example in IKE, with UDP messages containing long certificate chains. My rule of thumb is that trying to transmit UDP messages longer than 4K is guaranteed to fail spectacularly in at least some circumstances, and that only messages shorter than the IPv6 guaranteed minimal MTU are safe -- that is, about 1K in the payload. The practical options are, only use short presence documents, or use TCP. -- Christian Huitema > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 7:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; Patrick > Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does this preclude > any implementation (higher level application using SIP) from choosing to > send the body of the Notifies as incremental parts? It would seem that > the > SIP-level mechanisms would be unaware of the full nature of the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a mechanism. > > Mike > > > At 01:58 AM 11/21/2001 -0500, Jonathan Rosenberg wrote: > >I agree with Adam that defining a SIP specific fragmentation is a bad > thing. > >We have discussed this on the SIP list and it has been quickly squashed. > > > >For simple, a real delta versioning solution is the best thing. > > > >Another solution is TCP, which is generally better as far as firewall/nat > >traversal is concerned, not worse, and has none of these fragmentation > >issues. > > > >-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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Tuesday, November 20, 2001 6:50 PM > > > To: 'Brian Stucker'; simple > > > Cc: Alex Nava; Patrick Sollee; Sanjoy Sen > > > Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. > > > > > > > > > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > > > > > > > >Ok, you've really got me confused now. I even went off to > > > RFC-0760 (IP) and > > > >RFC-0768 (UDP) to make sure that I wasn't off in the weeds. > > > Even bis-05 SIP > > > talks > > > >about MTU problems. > > > > > > It makes a recommendation. If fragmentation were really a > > > problem, SIP would > > > mandate behavior. As it is, it's just trying to raise > > > awareness of some of > > > the related issues (like the two I discuss in a previous mail). > > > > > > >I don't think I'm off in the weeds, but I see what you're > > > referring to. > > > >I now see what you're getting at with the 64k size (maximum > > > datagram size), > > > but > > > >since IP makes no guarantee that any particular packet reaches it's > > > destination, it's > > > >really IP that is the problem. I see what you're getting at > > > with the UDP > > > packet > > > >being fragmented to the IP next-hop MTU size, but that means > > > that portions of > > > the UDP > > > >packet may go missing and unknown since IP doesn't do > > > anything to ensure that > > > any > > > >particular datagram makes it to the destination. > > > > > > That's a problem even when you don't exceed the MTU. That's why > > > SIP retransmits requests. > > > > > > There's a timer for reconstitution of the packet, sequence numbers, > > > a checksum, and all sorts of goodies in the UDP fragmentation to make > > > sure that it works. It's unreliable (but in an all-or-nothing sort > > > of way, just like all UDP datagram transmissions) but it works. All > > > you need is a mechanism to retransmit datagrams until they are > > > acknowledged, and SIP provides such a mechanism. > > > > > > >What's worse, is popular operating systems such as Microsoft Windows > > > >(with the possible exception of XP) specifically drops any datagram > > > >exceeding the MTU value until it receives an ARP response > > > for the first > > > >datagram (thus guaranteeing it to drop all of the portions of the UDP > > > >packet, except for the very last one: > > > >http://support.microsoft.com/support/kb/articles/q233/4/01.asp). > > > > > > I have two reactions to this: > > > > > > 1. Are you *seriously* proposing that we add provisions in the > > > protocol to work around Microsoft's buggy IP implementation? > > > > > > 2. Even with this special little Microsoft bug, it all works. > > > The first transmission of a UDP packet to a host might get > > > lost; however, this first transmission will load the ARP cache > > > for the destination, and the subsequent retransmissions will > > > progress as normal. > > > > > > I'm not arguing against your solution. I'm pointing out that > > > the "problem" you are trying to solve is not a problem. It might > > > be an inconvenience in corner cases, but it's not a problem. > > > > > > /a > > > > > > _______________________________________________ > > > 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 ------_=_NextPart_001_01C17659.5582FFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: Question regarding NOTIFY messages using = UDP.

Ok, here's a thought...

If we're in a position where we think we're going to = need to use TCP (or some other connection-oriented protocol) to notify = the watcher (in this example, a presence subscriber), but it's = difficult to keep up a bunch of TCP connections, we use the following = general mechanism.

1. We send the watcher a NOTIFY that says in effect = "you need to fetch the current state of this resource" (in = this case, probably using UDP).

2. The watcher responds to the NOTIFY with a 200 OK = however it chooses.
3. The watcher sends a SUBSCRIBE in to fetch the = current state of the resource (in this case a presentity) using the = transport of it's choosing. If it knows it's behind a firewall, or a = NAT, then it can pick TCP, for instance.

4. The presence agent responds to the SUBSCRIBE with = a 200 OK (because there shouldn't be any issues about authorization or = not).

5. The presence agent sends a NOTIFY to the watcher = using the same transport, IP, port, everything, that the fetch = SUBSCRIBE was received with.

Simple as that. We trigger a TCP connection inbound = from the client using a UDP message. NAT or not, it saves on having to = nail up a bunch of TCP connections for a long period of time, and it's = super easy to implement.

Events draft change:
All we'd need to change is to either add a new = reason to the subscription-expires header, like "stale" with = a non-zero value, and add a restriction that the state agent MUST = respond to a fetch using the same transport parameters used by the = watcher from the SUBSCRIBE.

-OR-

Events draft/watcherinfo change:
We add a new event to the watcherinfo format called = "stale" to the current list (subscribe, rejected, approved, = ...), and recommend that when a watcher to eventpkg.winfo receives = this event, they should perform a fetch. Then we add the change to the = events draft that when a fetch is performed, the source parameters from = the SUBSCRIBE should be used to send the NOTIFY.

Thoughts?

Brian Stucker

-----Original Message-----
From: Stucker, Brian [NGB:B635:EXCH]
Sent: Monday, November 26, 2001 2:15 AM
To: Christian Huitema; Michael Hammer; Jonathan = Rosenberg
Cc: adam.roach@ericsson.com; simple; Nava, Alex = [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy = [NGB:B692:EXCH]

Subject: RE: [Simple] RE: Question regarding NOTIFY = messages using UDP.


That's what I was afraid of.
TCP is incredibly expensive to use for presence = notification, in my mind, because the connection has to be baby-sitted = for extremely long periods of time to keep any potential pinholes open = in case a notify needs to be sent. That's bad. I know there are tons of = web servers out there that use TCP all the time, with no problem, but = they don't have to keep that connection up for very long. A flash in = the pan compared to what presence would do.

Hmmm....
Brian




-----Original Message-----
From: Christian Huitema [mailto:huitema@windows.mic= rosoft.com]
Sent: Friday, November 23, 2001 11:38 PM
To: Michael Hammer; Jonathan Rosenberg
Cc: adam.roach@ericsson.com; Stucker, Brian = [NGB:B635:EXCH]; simple;
Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick = [NGC:B680:EXCH]; Sen, Sanjoy
[NGB:B692:EXCH]
Subject: RE: [Simple] RE: Question regarding NOTIFY = messages using UDP.


I hope you are all aware that sending long messages = over UDP is a
*really bad idea*. The failure mode is the = following:
 1) long message gets fragmented in a set of = path-MTU sized IP messages;
 2) at least one message in the set is dropped = in the network;
 3) application times out and resend long = message;
 4) repeat step one.
The theory says that transmissions of independent = messages should result
in at least one transmission of the whole set = eventually, but the
independent error assumption is false in practice. = There are error
situations in which every fourth or fifth message = gets dropped, in which
case no amount of repetition solves the problem. = This is not
theoretical: I have seen the problem occur for = example in IKE, with UDP
messages containing long certificate chains.
My rule of thumb is that trying to transmit UDP = messages longer than 4K
is guaranteed to fail spectacularly in at least some = circumstances, and
that only messages shorter than the IPv6 guaranteed = minimal MTU are safe
-- that is, about 1K in the payload.
The practical options are, only use short presence = documents, or use
TCP.
-- Christian Huitema
> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Wednesday, November 21, 2001 7:11 AM =
> To: Jonathan Rosenberg
> Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; = simple; Alex Nava;
Patrick
> Sollee; Sanjoy Sen
> Subject: RE: [Simple] RE: Question regarding = NOTIFY messages using
UDP.
>
> Jonathan,
>
> While not favoring any fragmentation mechanism = for SIP, does this
preclude
> any implementation (higher level application = using SIP) from choosing
to
> send the body of the Notifies as incremental = parts?  It would seem
that
> the
> SIP-level mechanisms would be unaware of the = full nature of the body
which
> it carries and should place no restrictions on = that body.
>
> That is, it provides no mechanism nor precludes = use of such a
mechanism.
>
> Mike
>
>
> At 01:58 AM 11/21/2001 -0500, Jonathan = Rosenberg wrote:
> >I agree with Adam that defining a SIP = specific fragmentation is a bad
> thing.
> >We have discussed this on the SIP list and = it has been quickly
squashed.
> >
> >For simple, a real delta versioning = solution is the best thing.
> >
> >Another solution is TCP, which is generally = better as far as
firewall/nat
> >traversal is concerned, not worse, and has = none of these
fragmentation
> >issues.
> >
> >-Jonathan R.
> >
> >---
> >Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> >Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = >dynamicsoft         &nb= sp;           &nb= sp;           East = Hanover, NJ 07936
> = >jdrosen@dynamicsoft.com       &nb= sp;           &nb= sp; FAX:   (973) 952-5050
> >http://www.jdrosen.net    &nbs= p;           &nbs= p;     PHONE: (973) 952-5000
> >http://www.dynamicsoft.com
> >
> >
> > > -----Original Message-----
> > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> > > Sent: Tuesday, November 20, 2001 6:50 = PM
> > > To: 'Brian Stucker'; simple
> > > Cc: Alex Nava; Patrick Sollee; Sanjoy = Sen
> > > Subject: [Simple] RE: Question = regarding NOTIFY messages using
UDP.
> > >
> > >
> > > >From: Brian Stucker [mailto:bstucker@nortelnetwor= ks.com]
> > > >
> > > >Ok, you've really got me confused = now. I even went off to
> > > RFC-0760 (IP) and
> > > >RFC-0768 (UDP) to make sure that = I wasn't off in the weeds.
> > > Even bis-05 SIP
> > > talks
> > > >about MTU problems.
> > >
> > > It makes a recommendation. If = fragmentation were really a
> > > problem, SIP would
> > > mandate behavior. As it is, it's just = trying to raise
> > > awareness of some of
> > > the related issues (like the two I = discuss in a previous mail).
> > >
> > > >I don't think I'm off in the = weeds, but I see what you're
> > > referring to.
> > > >I now see what you're getting at = with the 64k size (maximum
> > > datagram size),
> > > but
> > > >since IP makes no guarantee that = any particular packet reaches
it's
> > > destination, it's
> > > >really IP that is the problem. I = see what you're getting at
> > > with the UDP
> > > packet
> > > >being fragmented to the IP = next-hop MTU size, but that means
> > > that portions of
> > > the UDP
> > > >packet may go missing and unknown = since IP doesn't do
> > > anything to ensure that
> > > any
> > > >particular datagram makes it to = the destination.
> > >
> > > That's a problem even when you don't = exceed the MTU. That's why
> > > SIP retransmits requests.
> > >
> > > There's a timer for reconstitution of = the packet, sequence
numbers,
> > > a checksum, and all sorts of goodies = in the UDP fragmentation to
make
> > > sure that it works. It's unreliable = (but in an all-or-nothing sort
> > > of way, just like all UDP datagram = transmissions) but it works.
All
> > > you need is a mechanism to retransmit = datagrams until they are
> > > acknowledged, and SIP provides such a = mechanism.
> > >
> > > >What's worse, is popular = operating systems such as Microsoft
Windows
> > > >(with the possible exception of = XP) specifically drops any
datagram
> > > >exceeding the MTU value until it = receives an ARP response
> > > for the first
> > > >datagram (thus guaranteeing it to = drop all of the portions of the
UDP
> > > >packet, except for the very last = one:
> > > >http://support.microsoft.com/support/kb/articles/q233/= 4/01.asp).
> > >
> > > I have two reactions to this:
> > >
> > > 1. Are you *seriously* proposing that = we add provisions in the
> > >    protocol to work = around Microsoft's buggy IP implementation?
> > >
> > > 2. Even with this special little = Microsoft bug, it all works.
> > >    The first = transmission of a UDP packet to a host might get
> > >    lost; however, this = first transmission will load the ARP cache
> > >    for the destination,= and the subsequent retransmissions will
> > >    progress as normal. =
> > >
> > > I'm not arguing against your = solution. I'm pointing out that
> > > the "problem" you are = trying to solve is not a problem. It might
> > > be an inconvenience in corner cases, = but it's not a problem.
> > >
> > > /a
> > >
> > > = _______________________________________________
> > > 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=

------_=_NextPart_001_01C17659.5582FFE0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 09:58:09 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01296 for ; Mon, 26 Nov 2001 09:58:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQEtO7x001336; Mon, 26 Nov 2001 09:55:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01335; Mon, 26 Nov 2001 09:57:09 -0500 (EST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA22474 for ; Sat, 24 Nov 2001 00:40:02 -0500 (EST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.195]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 23 Nov 2001 21:39:09 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 23 Nov 2001 21:39:09 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 23 Nov 2001 21:39:08 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 23 Nov 2001 21:39:06 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Fri, 23 Nov 2001 21:38:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. Message-ID: Thread-Topic: [Simple] RE: Question regarding NOTIFY messages using UDP. thread-index: AcFyn2gIe/yXTor7SIqJentUficy1ABuv3/A From: "Christian Huitema" To: "Michael Hammer" , "Jonathan Rosenberg" Cc: , "Brian Stucker" , "simple" , "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" X-OriginalArrivalTime: 24 Nov 2001 05:38:25.0965 (UTC) FILETIME=[3CFE5DD0:01C174AA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id AAA22474 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, 23 Nov 2001 21:38:25 -0800 Content-Transfer-Encoding: 8bit I hope you are all aware that sending long messages over UDP is a *really bad idea*. The failure mode is the following: 1) long message gets fragmented in a set of path-MTU sized IP messages; 2) at least one message in the set is dropped in the network; 3) application times out and resend long message; 4) repeat step one. The theory says that transmissions of independent messages should result in at least one transmission of the whole set eventually, but the independent error assumption is false in practice. There are error situations in which every fourth or fifth message gets dropped, in which case no amount of repetition solves the problem. This is not theoretical: I have seen the problem occur for example in IKE, with UDP messages containing long certificate chains. My rule of thumb is that trying to transmit UDP messages longer than 4K is guaranteed to fail spectacularly in at least some circumstances, and that only messages shorter than the IPv6 guaranteed minimal MTU are safe -- that is, about 1K in the payload. The practical options are, only use short presence documents, or use TCP. -- Christian Huitema > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 7:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; Patrick > Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does this preclude > any implementation (higher level application using SIP) from choosing to > send the body of the Notifies as incremental parts? It would seem that > the > SIP-level mechanisms would be unaware of the full nature of the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a mechanism. > > Mike > > > At 01:58 AM 11/21/2001 -0500, Jonathan Rosenberg wrote: > >I agree with Adam that defining a SIP specific fragmentation is a bad > thing. > >We have discussed this on the SIP list and it has been quickly squashed. > > > >For simple, a real delta versioning solution is the best thing. > > > >Another solution is TCP, which is generally better as far as firewall/nat > >traversal is concerned, not worse, and has none of these fragmentation > >issues. > > > >-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: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Tuesday, November 20, 2001 6:50 PM > > > To: 'Brian Stucker'; simple > > > Cc: Alex Nava; Patrick Sollee; Sanjoy Sen > > > Subject: [Simple] RE: Question regarding NOTIFY messages using UDP. > > > > > > > > > >From: Brian Stucker [mailto:bstucker@nortelnetworks.com] > > > > > > > >Ok, you've really got me confused now. I even went off to > > > RFC-0760 (IP) and > > > >RFC-0768 (UDP) to make sure that I wasn't off in the weeds. > > > Even bis-05 SIP > > > talks > > > >about MTU problems. > > > > > > It makes a recommendation. If fragmentation were really a > > > problem, SIP would > > > mandate behavior. As it is, it's just trying to raise > > > awareness of some of > > > the related issues (like the two I discuss in a previous mail). > > > > > > >I don't think I'm off in the weeds, but I see what you're > > > referring to. > > > >I now see what you're getting at with the 64k size (maximum > > > datagram size), > > > but > > > >since IP makes no guarantee that any particular packet reaches it's > > > destination, it's > > > >really IP that is the problem. I see what you're getting at > > > with the UDP > > > packet > > > >being fragmented to the IP next-hop MTU size, but that means > > > that portions of > > > the UDP > > > >packet may go missing and unknown since IP doesn't do > > > anything to ensure that > > > any > > > >particular datagram makes it to the destination. > > > > > > That's a problem even when you don't exceed the MTU. That's why > > > SIP retransmits requests. > > > > > > There's a timer for reconstitution of the packet, sequence numbers, > > > a checksum, and all sorts of goodies in the UDP fragmentation to make > > > sure that it works. It's unreliable (but in an all-or-nothing sort > > > of way, just like all UDP datagram transmissions) but it works. All > > > you need is a mechanism to retransmit datagrams until they are > > > acknowledged, and SIP provides such a mechanism. > > > > > > >What's worse, is popular operating systems such as Microsoft Windows > > > >(with the possible exception of XP) specifically drops any datagram > > > >exceeding the MTU value until it receives an ARP response > > > for the first > > > >datagram (thus guaranteeing it to drop all of the portions of the UDP > > > >packet, except for the very last one: > > > >http://support.microsoft.com/support/kb/articles/q233/4/01.asp). > > > > > > I have two reactions to this: > > > > > > 1. Are you *seriously* proposing that we add provisions in the > > > protocol to work around Microsoft's buggy IP implementation? > > > > > > 2. Even with this special little Microsoft bug, it all works. > > > The first transmission of a UDP packet to a host might get > > > lost; however, this first transmission will load the ARP cache > > > for the destination, and the subsequent retransmissions will > > > progress as normal. > > > > > > I'm not arguing against your solution. I'm pointing out that > > > the "problem" you are trying to solve is not a problem. It might > > > be an inconvenience in corner cases, but it's not a problem. > > > > > > /a > > > > > > _______________________________________________ > > > 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 10:45:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04688 for ; Mon, 26 Nov 2001 10:45:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQFgO7x001838; Mon, 26 Nov 2001 10:42:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01554; Mon, 26 Nov 2001 10:44:09 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01543 for ; Mon, 26 Nov 2001 10:43:02 -0500 (EST) Received: from dynamicsoft.com (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fAQFdOs12593; Mon, 26 Nov 2001 09:39:25 -0600 Message-ID: <3C02622C.9060206@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011115 X-Accept-Language: en-us MIME-Version: 1.0 To: Theodore Havinis CC: Jonathan Rosenberg , simple@mailman.dynamicsoft.com Subject: Re: [Simple] RE: Buddy list per User per Event service association ??? 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: Mon, 26 Nov 2001 09:39:24 -0600 Content-Transfer-Encoding: 7bit Hi Theo, Comments inline Theodore Havinis wrote: > Hi Ben, > > > Pls find my comments below. > > Thanks > /Theo > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Wednesday, November 21, 2001 12:56 PM >>To: Theodore Havinis >>Cc: Jonathan Rosenberg; simple@mailman.dynamicsoft.com >>Subject: Re: [Simple] RE: Buddy list per User per Event service >>association ??? >> >> >> >> >>Theodore Havinis wrote: >> >> >> >> >>>Thanks, it helped. >>>So, I have a buddy list, with buddies who subscribed to >>>my call event, and my call event buddy list gets updated >>> >>(through a watcher >> >>>client) about >>>my buddies presence, so I know who is available to be called and >>> >>who isn't >> >>>because they >>>appear to be as offline. >>>Does that make sense ? >>> >>> >>Actually, it does not. Your buddy list(s) are lists of people you >>subscribe to, not lists of people who subscribe to you. >> > > It coulbe be a matter of definition, but I also see as buddies of mine > anyone who wants to SUBSCRIBE to me and I authorize him/her. You are correct, it is a matter of definition. The definition I gave is the working definition used in the draft. > > > If you are > >>talking about automatically generating recipricol subscriptions, where >>you subscribe to everyone who subscribes to you, then that is an >>application level problem, not a protocol one. >> > > Not necessarily generating reciprocal subscriptions. > I agree this is an application issue. > > Nothing prevents an > >>application from automatically adding a user to your buddy list if you >>authorize them to subscribe to you. >> > > So here is the issue, and maybe its only a definition issue. > While in your first statement you say that my buddy list consists of people > that I subscribe > to, in your last statement you say that its also possible for somebody to > join my buddy list > provided I authorize his SUBSCRIBE request. No, I didn't say that. You (or an application on your behalf) add people to your buddy list. No one adds themselves to your buddy list. (Obviously there are exceptions, where you might grant a third party the right to add people to your list). Other people may choose to add you to their buddy lists. From a protocol level your buddy list and someone elses buddy list are completely decoupled. There is nothing that says that that you also subscribe to everyone that subscribes to you. This may be coincidentally true (you and a buddy just happen to subscribe to each other.) You might also write an application that enforces or facilitates this (Whenever you authorize someone to subscribe to you, the application automagically adds that person to your buddy list.) > > So the application is the entity which will decide if the person that wants > to SUBSCRIBE > to me is placed in the same buddy list with the persons that I have > subscribed to. > > But in principle, both the ones that I SUBSCRIBE to and the ones I authorize > to SUBSCRIBE to me > are buddies of mine and the key reason for that is "authorization" as I see > it. There is nothing at all to stop you from writing an application that uses the contents of your buddy list to make authorization decisions about people who wish to subscribe to you. In that case, you have a buddy list and an "authorized subscriber list" that just happen to be the same, or even two lists that happen to have the same contents. This is a matter of application policy and irrelevant to the draft. > > So, in my view it works both ways, and that can be used by an application on > my behalf > for building up say a buddy list consisting of people who accept my calls > when I call them, > and a buddy list of the people that I allow them to call me. > These two lists can be combined to one such "call service-buddy list" or can > be kept separate such as > 'incoming call service buddy list' and 'outgoing call service buddy list'. Again, it is perfectly reasonable to create an application where it works both ways. However, it is very useful when creating protocol to decouple the two concepts, making it also possible to create an interoperable application that does _not_ link the two. > > > Theo > > > > > > > > > > > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 10:54:56 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05801 for ; Mon, 26 Nov 2001 10:54:52 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQFqL7x001999; Mon, 26 Nov 2001 10:52:21 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01637; Mon, 26 Nov 2001 10:54:08 -0500 (EST) Received: from localhost.localdomain (dsl081-118-200.dfw1.dsl.speakeasy.net [64.81.118.200]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01626 for ; Mon, 26 Nov 2001 10:53:42 -0500 (EST) Received: from dynamicsoft.com (rocinante [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id fAQFo7s12600; Mon, 26 Nov 2001 09:50:08 -0600 Message-ID: <3C0264AF.6090600@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20011115 X-Accept-Language: en-us MIME-Version: 1.0 To: Hakan.Jonsson@bluelabs.se CC: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: Re: [Simple] new I-D on subscribing to buddy lists References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 26 Nov 2001 09:50:07 -0600 Content-Transfer-Encoding: 8bit Hi, comments inline Hakan.Jonsson@bluelabs.se wrote: > Some questions: > > - Why does the buddylist have a SIP URI of its own? A server supporting the > buddylist package has enough information in the from header to perform its > task. A PUA and a PA communicates without having to adress the PA > specifically. Well, aside from the fact that it is dangerous to attribute any meaning to the From header other than as part of call-leg/transaction identification, using the request-URI approach is much more flexible. For example, I might have multiple buddy lists for the same user. Or perhaps even more interesting would be to have a buddy list that can be used by more than one user. > > - I think it should be possible to see that the buddylist event package is > a delegated presence subscription event package, by making it a subpackage > (or perhaps a superpackage), e.g. presence.buddylist (or > buddylist.presence). I should be possible to perform delegated > subscriptions to other event packages e.g. buddylist.myeventpackagename. > The word buddylist would then not be very useful in itself; > presence.delegate is my suggestion. I don't suppose it really matters what you name it, although it might be useful to capture the idea, that in addition to delegation, you are agreggating subscriptions, that is, subscribing to more than one presentity in a single subscription. > > The latter could perhaps be used in some way to join subscriptions. Say > that I have made a SUBCRIBE request for the presence.delegate package and > later make a SUBSCRIBE request for an individual user, it would be very > useful to join the individual subscription to the delegated subscription. I > am not sure how though (yet). Wow, the thought makes my head hurt :-) I suspect any _protocol_ level solution to that would add a lot of complexity for a corner use case. I think that sort of thing is better left to individual implementation decisions. (Assuming an app could detect the condition, it could disallow the second subscription, or drop the presentity from the current buddy list subscription, etc.) > > Regards, > > Håkan Jonsson > > _______________________________________________ > 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 Mon Nov 26 13:12:42 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17613 for ; Mon, 26 Nov 2001 13:12:42 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQI9M7x003255; Mon, 26 Nov 2001 13:09:57 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02176; Mon, 26 Nov 2001 13:11:09 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02165 for ; Mon, 26 Nov 2001 13:10:01 -0500 (EST) From: adam.roach@ericsson.com Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fAQHEPH24828; Mon, 26 Nov 2001 11:14:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAQHEPX05540; Mon, 26 Nov 2001 11:14:25 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id LAA03737; Mon, 26 Nov 2001 11:14:24 -0600 (CST) Reply-To: To: "'Jonathan Rosenberg'" , "'Brian Stucker'" , "adam.roach" , "simple" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C70@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 26 Nov 2001 11:14:23 -0600 Content-Transfer-Encoding: 7bit That works, but it seems like a lot of extra implementation effort. There's really nothing magical about the dialog established by the 200-class response to the SUBSCRIBE; it's just an arbitrary leg which happens to have responded first. Given that fact, why don't we just change the scheme so that the dialog associated with the SUBSCRIBE response isn't special, and we just accept the first NOTIFY that arrives (and reject all the other dialogs)? Is there something I'm overlooking? Accepting the first NOTIFY seems much easier to implement than keeping track of dialogs that will just need to be torn down. /a > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, November 21, 2001 2:00 PM > To: 'Brian Stucker'; adam.roach; simple > Subject: RE: [Simple] 200 vs. 202 > > > how about this: > > 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it > accepts the > NOTIFY > 2. once the response to the SUBSCRIBE comes, if its not a > match for the > NOTIFY, the subscriber refreshes the dialog associated with > the NOTIFY, but > with Expires:0, to terminate it. > > This avoids the tight transaction timing interdependencies at > the expense of > some additional higher level processing. > > BTW, this is really a sip-events issue not so much a simple issue. > > -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: Wednesday, November 21, 2001 2:23 PM > To: adam.roach; simple > Subject: RE: [Simple] 200 vs. 202 > > > You bring up an important point about the watcher having to > wait for the > response to the SUBSCRIBE before processing the NOTIFY. This > could give us > problems if the 200 takes a long time getting back to the > watcher, and the > NOTIFY, in the meantime, is just sitting there being > retransmitted over and > over, waiting for a response. Depending on the T1 and T2 > timers being used, > this could create a race condition that might cause a > subscription to fail > because there was no response to the immediate NOTIFY. > In general, what happens when a NOTIFY to the inital > SUBSCRIBE fails to be > acknowledged? Does the subscription go away like it does for > later NOTIFY > messages? The reason I ask, is because it would seem to leave > the watcher in > an undefined state. What are the responsibilities of a > watcher that sends a > SUBSCRIBE, gets a 200, and then no NOTIFY? > A possible solution would be to silently throw away and > NOTIFY messages that > we have not gotten a response (200) on the request to create > a dialogue for > (the SUBSCRIBE). If we do that, then we could wait for some > period of time > (say the expires header in the 200 response). If that period > of time elapses > without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). > Thoughts? > Brian > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Tuesday, November 20, 2001 3:18 PM > To: simple > Subject: RE: [Simple] 200 vs. 202 > > > While I disagree with Brian and Jonathan about the problems presented > by having multiple PAs in the network, I am willing to quit the topic > for the sake of moving forward. > I am very wary, however, of any discussions which use arguments about > the general case of forking of SUBSCRIBE requests instead of those > involving multiple PAs. I wouldn't have even entered the fray if the > arguments presented by several parties didn't attack the very notion > of SUBSCRIBE forking (instead of limiting themselves to presence in > particular). > So, with my capitulation, I'll attempt to enumerate what I think > we've all agreed on: > 1. SUBSCRIBE requests may fork. > 2. Subscribers may choose to accept zero or more of the > NOTIFY requests that arrive by responding to them with > a 200. > 3. Subscribers may choose to reject zero or more of the > NOTIFY requests that arrive by responding to them with > a 481. > 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I > don't personally care which) accept exactly one NOTIFY > message with a 200, and reject all others with a 481. > 5. Subscribers _to_ _presence_ _information_ select which > NOTIFY to accept based on the dialog information > established by the 2xx response to the SUBSCRIBE. > Moving forward, then, I see two sets of problems to be addressed: > Forking SUBSCRIBE: > - How do we perform authentication for forked SUBSCRIBE messages? > This is actually a more general problem which can be phrased > "How do we perform authentication for forked XXX messages?" where > XXX includes INVITE. I would *really*, *really* like to see a > more general solution to this problem before we start trying > to cobble something together for SUBSCRIBE. > - How do we protect against the DOS attacks that Robert describes? > Presence: > - In a forking situation, it is likely (probable, even) that the > NOTIFY requests will arrive at the subscriber before the 2xx > reply to the SUBSCRIBE. Does that mean that the response to the > NOTIFY requests will be suppressed until the SUBSCRIBE request > completes? If so, this should be well documented in the > presence event package. > - Some of the arguments made against accepting multiple dialogs > created by a single SUBSCRIBE were privacy based: an aggregation > point must exist in the network to provide a consistent policy. > Given that there is no way to enforce that only one dialog is > accepted, are there any privacy concerns that can arise from > rogue clients accepting all received NOTIFYs? > /a > _______________________________________________ > 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 Mon Nov 26 13:49:51 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20273 for ; Mon, 26 Nov 2001 13:49:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQIlL7x003796; Mon, 26 Nov 2001 13:47:21 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02331; Mon, 26 Nov 2001 13:49:09 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02320 for ; Mon, 26 Nov 2001 13:48:20 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAQIlwT04663; Mon, 26 Nov 2001 13:47:58 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAE07747 (AUTH pkyzivat); Mon, 26 Nov 2001 13:49:18 -0500 (EST) Message-ID: <3C028DA5.953ECC9B@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: Content-Type: text/plain; charset=us-ascii 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: Mon, 26 Nov 2001 13:44:53 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Indeed. I have in fact written a draft on doing just that: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt Intesting paper. I think that a procedure of this sort is definitely needed. Here are some specific comments/questions about the details of what you propose: - what if the problem wasn't with the endpoint at all, but rather was an intermittent problem with the network? In that case, both ends may try to initiate recovery. (The analogy in the PSTN is the familiar "we were disconnected, but when I tried to call back your line was busy" problem.) - what if there is no problem with signalling but there is a problem with the media stream? Then the reinvite will reach the original endpoint rather than a backup. It will not be able to distinguish this reinvite from one for some other purpose, like session timer refresh. It will note that the sdp has not changed, and may choose to simply return the last sdp it sent. (This could happen if the sip and media travel on different network connections to the same host, or if the media is on a separate device with its own network connection.) - your 3pcc example requires that the controller forward on all reinvites, even if nothing in the sdp has changed. However there are other cases where this is a bad thing. There may well be reinvites going on simply to update session timers. Since the session timer schedule may differ on the two legs, it isn't desirable to forward noop invites. - in a separate mail thread on the comedia draft, we identified some added problems with reinvites and connection oriented media. In that case, what is negotiated in the sdp is used to establish a media connection, so it isn't idempotent to subsequent invitations. There is need to indicate in the sdp whether to renegotiate the connection or not. I don't think we ever fully resolved that. But I believe it is important that something in the sdp be changed to indicate a desire to renegotiate the connection. The same kind of scenario applies here. All of these issues suggest to me that some explicit information needs to be conveyed indicating what is being attempted. Part of this might be a Reason header indicating that the reinvite is being sent to recover from a perceived problem. In addition, I think there needs to be something in the SDP to indicate what needs to be done. One possibility I have suggested elsewhere is to extend sdp to permit an o= line for each media description. This could then be revised to indicate a desire to renegotiate the media stream without changing the caller's end. (This could also be indicated with a new kind of a= line.) Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 14:19:00 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22752 for ; Mon, 26 Nov 2001 14:18:59 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQJGO7x004153; Mon, 26 Nov 2001 14:16:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02477; Mon, 26 Nov 2001 14:18:09 -0500 (EST) 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 OAA02465 for ; Mon, 26 Nov 2001 14:17:04 -0500 (EST) 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 NAA01097 for ; Mon, 26 Nov 2001 13:16:22 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Mon, 26 Nov 2001 13:06:57 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 13:12:45 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EEFA306@zrc2c012.us.nortel.com> From: "Brian Stucker" To: "adam.roach" , "'Jonathan Rosenberg'" , 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_01C176AE.53144930" 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: Mon, 26 Nov 2001 13:12:43 -0600 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_01C176AE.53144930 Content-Type: text/plain; charset="iso-8859-1" At the risk of being flogged (I am not suggesting reopening how we do forking in SIP events)... Wouldn't just accepting the first NOTIFY go completely against the forking rules, etc., in your draft, or are we allowing presence to go it's own direction in this regard? Just taking the first NOTIFY makes it seem like the argument of a 3-way handshake with the response to the SUBSCRIBE isn't all that important. One thing I wonder about is "grinching" the watcher with this. If I have a fast presence agent (one with very little information to send in the NOTIFY), and a slow presence agent (one with lots of information to send in the NOTIFY, and a more complete presence picture); does being the fastest to respond mean that the information provided is the best as well? Seems like a race condition waiting to happen. Regards, Brian Stucker -----Original Message----- From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] Sent: Monday, November 26, 2001 11:14 AM To: 'Jonathan Rosenberg'; Stucker, Brian [NGB:B635:EXCH]; adam.roach; simple Subject: RE: [Simple] 200 vs. 202 That works, but it seems like a lot of extra implementation effort. There's really nothing magical about the dialog established by the 200-class response to the SUBSCRIBE; it's just an arbitrary leg which happens to have responded first. Given that fact, why don't we just change the scheme so that the dialog associated with the SUBSCRIBE response isn't special, and we just accept the first NOTIFY that arrives (and reject all the other dialogs)? Is there something I'm overlooking? Accepting the first NOTIFY seems much easier to implement than keeping track of dialogs that will just need to be torn down. /a > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, November 21, 2001 2:00 PM > To: 'Brian Stucker'; adam.roach; simple > Subject: RE: [Simple] 200 vs. 202 > > > how about this: > > 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it > accepts the > NOTIFY > 2. once the response to the SUBSCRIBE comes, if its not a > match for the > NOTIFY, the subscriber refreshes the dialog associated with > the NOTIFY, but > with Expires:0, to terminate it. > > This avoids the tight transaction timing interdependencies at > the expense of > some additional higher level processing. > > BTW, this is really a sip-events issue not so much a simple issue. > > -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: Wednesday, November 21, 2001 2:23 PM > To: adam.roach; simple > Subject: RE: [Simple] 200 vs. 202 > > > You bring up an important point about the watcher having to > wait for the > response to the SUBSCRIBE before processing the NOTIFY. This > could give us > problems if the 200 takes a long time getting back to the > watcher, and the > NOTIFY, in the meantime, is just sitting there being > retransmitted over and > over, waiting for a response. Depending on the T1 and T2 > timers being used, > this could create a race condition that might cause a > subscription to fail > because there was no response to the immediate NOTIFY. > In general, what happens when a NOTIFY to the inital > SUBSCRIBE fails to be > acknowledged? Does the subscription go away like it does for > later NOTIFY > messages? The reason I ask, is because it would seem to leave > the watcher in > an undefined state. What are the responsibilities of a > watcher that sends a > SUBSCRIBE, gets a 200, and then no NOTIFY? > A possible solution would be to silently throw away and > NOTIFY messages that > we have not gotten a response (200) on the request to create > a dialogue for > (the SUBSCRIBE). If we do that, then we could wait for some > period of time > (say the expires header in the 200 response). If that period > of time elapses > without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). > Thoughts? > Brian > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Tuesday, November 20, 2001 3:18 PM > To: simple > Subject: RE: [Simple] 200 vs. 202 > > > While I disagree with Brian and Jonathan about the problems presented > by having multiple PAs in the network, I am willing to quit the topic > for the sake of moving forward. > I am very wary, however, of any discussions which use arguments about > the general case of forking of SUBSCRIBE requests instead of those > involving multiple PAs. I wouldn't have even entered the fray if the > arguments presented by several parties didn't attack the very notion > of SUBSCRIBE forking (instead of limiting themselves to presence in > particular). > So, with my capitulation, I'll attempt to enumerate what I think > we've all agreed on: > 1. SUBSCRIBE requests may fork. > 2. Subscribers may choose to accept zero or more of the > NOTIFY requests that arrive by responding to them with > a 200. > 3. Subscribers may choose to reject zero or more of the > NOTIFY requests that arrive by responding to them with > a 481. > 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I > don't personally care which) accept exactly one NOTIFY > message with a 200, and reject all others with a 481. > 5. Subscribers _to_ _presence_ _information_ select which > NOTIFY to accept based on the dialog information > established by the 2xx response to the SUBSCRIBE. > Moving forward, then, I see two sets of problems to be addressed: > Forking SUBSCRIBE: > - How do we perform authentication for forked SUBSCRIBE messages? > This is actually a more general problem which can be phrased > "How do we perform authentication for forked XXX messages?" where > XXX includes INVITE. I would *really*, *really* like to see a > more general solution to this problem before we start trying > to cobble something together for SUBSCRIBE. > - How do we protect against the DOS attacks that Robert describes? > Presence: > - In a forking situation, it is likely (probable, even) that the > NOTIFY requests will arrive at the subscriber before the 2xx > reply to the SUBSCRIBE. Does that mean that the response to the > NOTIFY requests will be suppressed until the SUBSCRIBE request > completes? If so, this should be well documented in the > presence event package. > - Some of the arguments made against accepting multiple dialogs > created by a single SUBSCRIBE were privacy based: an aggregation > point must exist in the network to provide a consistent policy. > Given that there is no way to enforce that only one dialog is > accepted, are there any privacy concerns that can arise from > rogue clients accepting all received NOTIFYs? > /a > _______________________________________________ > 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 ------_=_NextPart_001_01C176AE.53144930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] 200 vs. 202

At the risk of being flogged (I am not suggesting = reopening how we do forking in SIP events)...

Wouldn't just accepting the first NOTIFY go = completely against the forking rules, etc., in your draft, or are we = allowing presence to go it's own direction in this regard? Just taking = the first NOTIFY makes it seem like the argument of a 3-way handshake = with the response to the SUBSCRIBE isn't all that important.

One thing I wonder about is "grinching" the = watcher with this. If I have a fast presence agent (one with very = little information to send in the NOTIFY), and a slow presence agent = (one with lots of information to send in the NOTIFY, and a more = complete presence picture); does being the fastest to respond mean that = the information provided is the best as well? Seems like a race = condition waiting to happen.

Regards,

Brian Stucker

-----Original Message-----
From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
Sent: Monday, November 26, 2001 11:14 AM
To: 'Jonathan Rosenberg'; Stucker, Brian = [NGB:B635:EXCH]; adam.roach;
simple
Subject: RE: [Simple] 200 vs. 202


That works, but it seems like a lot of extra = implementation effort.

There's really nothing magical about the dialog = established by the
200-class response to the SUBSCRIBE; it's just an = arbitrary leg
which happens to have responded first.

Given that fact, why don't we just change the scheme = so that the
dialog associated with the SUBSCRIBE response isn't = special, and
we just accept the first NOTIFY that arrives (and = reject all the
other dialogs)?

Is there something I'm overlooking? Accepting the = first NOTIFY
seems much easier to implement than keeping track of = dialogs that
will just need to be torn down.

/a

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, November 21, 2001 2:00 = PM
> To: 'Brian Stucker'; adam.roach; simple
> Subject: RE: [Simple] 200 vs. 202
>
>
> how about this:
>
> 1. if the subscriber hasn't gotten a 2xx to the = SUBSCRIBE, it
> accepts the
> NOTIFY
> 2. once the response to the SUBSCRIBE comes, if = its not a
> match for the
> NOTIFY, the subscriber refreshes the dialog = associated with
> the NOTIFY, but
> with Expires:0, to terminate it.
>
> This avoids the tight transaction timing = interdependencies at
> the expense of
> some additional higher level processing.
>
> BTW, this is really a sip-events issue not so = much a simple issue.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg, = Ph.D.           &= nbsp;    72 Eagle Rock Ave.
> Chief = Scientist          &nb= sp;           &nb= sp;      First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;          East = Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;            = 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: Wednesday, November 21, 2001 2:23 = PM
> To: adam.roach; simple
> Subject: RE: [Simple] 200 vs. 202
>
>
> You bring up an important point about the = watcher having to
> wait for the
> response to the SUBSCRIBE before processing the = NOTIFY. This
> could give us
> problems if the 200 takes a long time getting = back to the
> watcher, and the
> NOTIFY, in the meantime, is just sitting there = being
> retransmitted over and
> over, waiting for a response. Depending on the = T1 and T2
> timers being used,
> this could create a race condition that might = cause a
> subscription to fail
> because there was no response to the immediate = NOTIFY.
> In general, what happens when a NOTIFY to the = inital
> SUBSCRIBE fails to be
> acknowledged?  Does the subscription go = away like it does for
> later NOTIFY
> messages? The reason I ask, is because it would = seem to leave
> the watcher in
> an undefined state. What are the = responsibilities of a
> watcher that sends a
> SUBSCRIBE, gets a 200, and then no = NOTIFY?
> A possible solution would be to silently throw = away and
> NOTIFY messages that
> we have not gotten a response (200) on the = request to create
> a dialogue for
> (the SUBSCRIBE). If we do that, then we could = wait for some
> period of time
> (say the expires header in the 200 response). = If that period
> of time elapses
> without a NOTIFY, then we send the SUBSCRIBE = again (if we got a 200).
> Thoughts?
> Brian
> -----Original Message-----
> From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com]
> Sent: Tuesday, November 20, 2001 3:18 PM =
> To: simple
> Subject: RE: [Simple] 200 vs. 202
>
>
> While I disagree with Brian and Jonathan about = the problems presented
> by having multiple PAs in the network, I am = willing to quit the topic
> for the sake of moving forward.
> I am very wary, however, of any discussions = which use arguments about
> the general case of forking of SUBSCRIBE = requests instead of those
> involving multiple PAs. I wouldn't have even = entered the fray if the
> arguments presented by several parties didn't = attack the very notion
> of SUBSCRIBE forking (instead of limiting = themselves to presence in
> particular).
> So, with my capitulation, I'll attempt to = enumerate what I think
> we've all agreed on:
>  1. SUBSCRIBE requests may fork.
>  2. Subscribers may choose to accept zero = or more of the
>     NOTIFY requests that = arrive by responding to them with
>     a 200.
>  3. Subscribers may choose to reject zero = or more of the
>     NOTIFY requests that = arrive by responding to them with
>     a 481.
>  4. Subscribers _to_ _presence_ = _information_ SHOULD or MUST (I
>     don't personally care = which) accept exactly one NOTIFY
>     message with a 200, and = reject all others with a 481.
>  5. Subscribers _to_ _presence_ = _information_ select which
>     NOTIFY to accept based = on the dialog information
>     established by the 2xx = response to the SUBSCRIBE.
> Moving forward, then, I see two sets of = problems to be addressed:
> Forking SUBSCRIBE:
>   - How do we perform authentication = for forked SUBSCRIBE messages?
>     This is actually a more = general problem which can be phrased
>     "How do we perform = authentication for forked XXX messages?" where
>     XXX includes INVITE. I = would *really*, *really* like to see a
>     more general solution = to this problem before we start trying
>     to cobble something = together for SUBSCRIBE.
>   - How do we protect against the DOS = attacks that Robert describes?
> Presence:
>   - In a forking situation, it is = likely (probable, even) that the
>     NOTIFY requests will = arrive at the subscriber before the 2xx
>     reply to the SUBSCRIBE. = Does that mean that the response to the
>     NOTIFY requests will be = suppressed until the SUBSCRIBE request
>     completes? If so, this = should be well documented in the
>     presence event package. =
>   - Some of the arguments made = against accepting multiple dialogs
>     created by a single = SUBSCRIBE were privacy based: an aggregation
>     point must exist in the = network to provide a consistent policy.
>     Given that there is no = way to enforce that only one dialog is
>     accepted, are there any = privacy concerns that can arise from
>     rogue clients accepting = all received NOTIFYs?
> /a
> _______________________________________________ =
> 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=

------_=_NextPart_001_01C176AE.53144930-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 14:35:48 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23856 for ; Mon, 26 Nov 2001 14:35:48 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQJXM7x004386; Mon, 26 Nov 2001 14:33:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02593; Mon, 26 Nov 2001 14:35:10 -0500 (EST) 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 OAA02579 for ; Mon, 26 Nov 2001 14:34:06 -0500 (EST) 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 fAQJWG7x004360; Mon, 26 Nov 2001 14:32:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 14:33:42 -0500 Message-ID: From: Jonathan Rosenberg To: Ben Campbell , Hakan.Jonsson@bluelabs.se Cc: Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" Subject: RE: [Simple] new I-D on subscribing to buddy lists 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, 26 Nov 2001 14:33:35 -0500 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, November 26, 2001 10:50 AM > To: Hakan.Jonsson@bluelabs.se > Cc: Jonathan Rosenberg; 'simple@mailman.dynamicsoft.com' > Subject: Re: [Simple] new I-D on subscribing to buddy lists > > > > > - I think it should be possible to see that the buddylist > event package is > > a delegated presence subscription event package, by making > it a subpackage > > (or perhaps a superpackage), e.g. presence.buddylist (or > > buddylist.presence). I should be possible to perform delegated > > subscriptions to other event packages e.g. > buddylist.myeventpackagename. > > The word buddylist would then not be very useful in itself; > > presence.delegate is my suggestion. > > > I don't suppose it really matters what you name it, although > it might be > useful to capture the idea, that in addition to delegation, you are > agreggating subscriptions, that is, subscribing to more than one > presentity in a single subscription. The draft already talks about the possibility of this being a more general purpose sub-package. See section 5: 1. The concept here can be generalized into a sub-package. Effectively, it could be the "aggregation" sub-package for any package, and allow for subscriptions to a list of elements of the parent package type. The default body of the sub-package would be the same as the parent package, but also allow for multipart/mixed and possibly a type specific to the parent package. Therefore, instead of "buddylist", we would have "presence.aggregate". I suspect that this generalization is a good thing, much like it was for watcherinfo. > > > > > > The latter could perhaps be used in some way to join > subscriptions. Say > > that I have made a SUBCRIBE request for the > presence.delegate package and > > later make a SUBSCRIBE request for an individual user, it > would be very > > useful to join the individual subscription to the delegated > subscription. I > > am not sure how though (yet). > > > Wow, the thought makes my head hurt :-) I suspect any > _protocol_ level > solution to that would add a lot of complexity for a corner > use case. I > think that sort of thing is better left to individual implementation > decisions. (Assuming an app could detect the condition, it could > disallow the second subscription, or drop the presentity from the > current buddy list subscription, etc.) I don't like the idea of states of subscriptions affecting each other. It makes a lot more sense to keep these separate. Indeed, there may very well be reasons why a client wishes to have a group and an individual subscription separately. You don't want the server to make assumptions about what the client is trying to achieve. -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 Mon Nov 26 14:53:50 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25150 for ; Mon, 26 Nov 2001 14:53:50 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQJpL7x004647; Mon, 26 Nov 2001 14:51:21 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02701; Mon, 26 Nov 2001 14:53:09 -0500 (EST) 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 OAA02689 for ; Mon, 26 Nov 2001 14:52:44 -0500 (EST) 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 fAQJev7x004522; Mon, 26 Nov 2001 14:40:58 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 14:42:24 -0500 Message-ID: From: Jonathan Rosenberg To: "'adam.roach@ericsson.com'" , Jonathan Rosenberg , "'Brian Stucker'" , simple 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: Mon, 26 Nov 2001 14:42:20 -0500 > -----Original Message----- > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > Sent: Monday, November 26, 2001 12:14 PM > To: 'Jonathan Rosenberg'; 'Brian Stucker'; adam.roach; simple > Subject: RE: [Simple] 200 vs. 202 > > > That works, but it seems like a lot of extra implementation effort. > > There's really nothing magical about the dialog established by the > 200-class response to the SUBSCRIBE; it's just an arbitrary leg > which happens to have responded first. > > Given that fact, why don't we just change the scheme so that the > dialog associated with the SUBSCRIBE response isn't special, and > we just accept the first NOTIFY that arrives (and reject all the > other dialogs)? > > Is there something I'm overlooking? Accepting the first NOTIFY > seems much easier to implement than keeping track of dialogs that > will just need to be torn down. I think thats a good idea. Its clearly simpler than my initial proposal. The whole authentication business makes me a little nervous; I suppose the NOTIFY would simply be authenticated independently so it should be OK, but it requires some more thought. I still think this is really a sip-events issue, not a simple issue. From sip-events: Each event package should specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions. If such behavior is not allowed, any NOTIFY messages not matching the 200-class response to the initial SUBSCRIBE message are responded to with a 481. But this doesn't work. Rather, it should say: Each event package should specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions. If such behavior is not allowed, the first NOTIFY is responded to with a 200 OK, and all others are rejected with a 481. -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 Mon Nov 26 15:40:10 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29050 for ; Mon, 26 Nov 2001 15:40:08 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQKaX7x005125; Mon, 26 Nov 2001 15:36:33 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02907; Mon, 26 Nov 2001 15:38:10 -0500 (EST) Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02895 for ; Mon, 26 Nov 2001 15:37:49 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fAQKZdZ07858; Mon, 26 Nov 2001 15:35:48 -0500 (EST) Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id PAA03157; Mon, 26 Nov 2001 15:34:15 -0500 (EST) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 15:35:34 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F958BD12@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: mankin@isi.edu, Jon.Peterson@NeuStar.com Cc: simple MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] I-D: Guidelines for IM Sessions 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, 26 Nov 2001 15:35:18 -0500 Hi, Allison and Jon: The draft for "Guidelines for IM and Presence is an excellent one. It provides us clear pictures how the standards need to be developed and what issues need to be addressed that are not usually apparent to many of us. I have two requests as follows: 1. Can we include a statement in "Normative Guidelines" section that IM sessions can also be integrated with audio and/or video sessions (or similar statement), if needed? 2. Can we expect a similar draft for "Presence" as well? Best regards, Radhika R. Roy rrroy@att.com _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 15:47:27 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29824 for ; Mon, 26 Nov 2001 15:47:25 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQKiM7x005234; Mon, 26 Nov 2001 15:44:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02966; Mon, 26 Nov 2001 15:46:10 -0500 (EST) 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 PAA02950 for ; Mon, 26 Nov 2001 15:45:21 -0500 (EST) 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 fAQK1q7x004797; Mon, 26 Nov 2001 15:01:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 15:03:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Michael Hammer'" , Jonathan Rosenberg Cc: "'adam.roach@ericsson.com'" , "'Brian Stucker'" , simple , Alex Nava , Patrick Sollee , Sanjoy Sen Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. 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, 26 Nov 2001 15:03:08 -0500 > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 10:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; > Patrick Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages > using UDP. > > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does > this preclude > any implementation (higher level application using SIP) from > choosing to > send the body of the Notifies as incremental parts? It would > seem that the > SIP-level mechanisms would be unaware of the full nature of > the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a > mechanism. The spec assumes full-state, and talks about using CSeq to determine the most recent document, which wouldn't make sense for partial documents as you have described. An extension could in principle override this, and you could define a document format that supports partial information. However, I still assert that: 1. this is a problem in theory only 2. if the docs do become large, delta encoding is better Honestly, the problem is more for other event packages that may convey larger amounts of state. Brian later writes: > Ok, here's a thought... > If we're in a position where we think we're going to need to use TCP (or some other > connection-oriented protocol) to notify the watcher (in this example, a presence > subscriber), but it's difficult to keep up a bunch of TCP connections, we use the > following general mechanism. > > 1. We send the watcher a NOTIFY that says in effect "you need to fetch the current state > of this resource" (in this case, probably using UDP). > > 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. > > 3. The watcher sends a SUBSCRIBE in to fetch the current state of the resource (in this > case a presentity) using the transport of it's choosing. If it knows it's behind a > firewall, or a NAT, then it can pick TCP, for instance. Actually, we've been toying with the idea of not even using SUBSCRIBE for this. An HTTP request is just fine for synchronously fetching a document; thats what its designed to do. One could think of this as another sub-package, say "alert". If you subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY contains a body type that is always short - providing a URL for actually retrieving the thing that has changed. In fact, the default could be as simple as application/uri-list. So: SUBSCRIBE sip:user@domain.com SIP/2.0 Event: presence.alert Accept: application/uri-list then the NOTIFY: NOTIFY sip:subscriber@school.edu SIP/2.0 Event: presence.alert Content-Type: application/uri-list http://school.edu/user/current-pres-doc.pl One might even have multipel URI there of several schemes, supporting a variety of pulls. -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 Mon Nov 26 16:08:35 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01760 for ; Mon, 26 Nov 2001 16:08:32 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQL5P7x005456; Mon, 26 Nov 2001 16:05:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03057; Mon, 26 Nov 2001 16:07:09 -0500 (EST) 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 QAA03046 for ; Mon, 26 Nov 2001 16:06:05 -0500 (EST) 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 fAQL4C7x005443; Mon, 26 Nov 2001 16:04:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 16:05:39 -0500 Message-ID: From: Jonathan Rosenberg To: "'Torrey Searle'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] CPIM and Presence 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, 26 Nov 2001 16:05:36 -0500 > -----Original Message----- > From: Torrey Searle [mailto:tsearle@antihe.ro] > Sent: Thursday, November 22, 2001 6:07 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] CPIM and Presence > > > In the 01 version of the CPIM draft, it appears to indicate > that the presentity element is a required element of the > presence element, however the call flows in the Presence RFC > omit this element, should this element be added in future > versions of the Draft? Yes. Thanks for pointing this out. > > Also in the Presence call flows, an element called detail > appears in the status element to indicate im status, however > it appears to be the same as the value element in the CPIM > draft, the only difference being that the type paraleter has > a value of "urn:ietf:params:cpim-presence:status-type:im" can > the presence draft be updated to match? Yes. I didn't fix the flows to get them up to speed with cpim-pidf. -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 Mon Nov 26 16:13:19 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02133 for ; Mon, 26 Nov 2001 16:13:17 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQL9P7x005538; Mon, 26 Nov 2001 16:09:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03092; Mon, 26 Nov 2001 16:11:09 -0500 (EST) 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 QAA03081 for ; Mon, 26 Nov 2001 16:10:57 -0500 (EST) 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 fAQL937x005506; Mon, 26 Nov 2001 16:09:03 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 26 Nov 2001 16:10:30 -0500 Message-ID: From: Jonathan Rosenberg To: "'Torrey Searle'" , simple@mailman.dynamicsoft.com Subject: RE: [Simple] question on presence callflow 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, 26 Nov 2001 16:10:28 -0500 > -----Original Message----- > From: Torrey Searle [mailto:tsearle@antihe.ro] > Sent: Thursday, November 22, 2001 5:52 AM > To: simple@mailman.dynamicsoft.com > Subject: [Simple] question on presence callflow > > > In the callflow example 8.2 of the presence document 04, > there is a call flow for the presentity changing state, > however there are afew strange things about it > > 1. the presentity state doesn't change, it both notifies > indicate the state as open/available Good point. I will fix this. > > 2. upon the state change, the PUA sends a register to the PA, > persumably to update it's presence info using the REGISTER > method, however, aside from stating support for SUBSCRIBE > (which it also did in the inital invite) there is no presence > state information contained in the register) Same error as above. > > > I notice that in older versions on the draft, this example > used to show a transition from open/available to closed/busy > and the register updating the presence info using the > description parameter defined in the caller preferences > extension, since section 6.2 of the 04 presence document > still recommends the use of the caller preferences extension > to update state of the presentity, why was this parameter > dropped from the current call flow? Description is really not quite the right thing to set the note in the presence document. However, there should be some kind of state change here, driven by caller preferences. -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 Mon Nov 26 16:27:03 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03044 for ; Mon, 26 Nov 2001 16:27:02 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQLNS7x005717; Mon, 26 Nov 2001 16:23:29 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03169; Mon, 26 Nov 2001 16:25:11 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03156 for ; Mon, 26 Nov 2001 16:24:48 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAQLOQT19972; Mon, 26 Nov 2001 16:24:26 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAE09206 (AUTH pkyzivat); Mon, 26 Nov 2001 16:25:45 -0500 (EST) Message-ID: <3C02B250.65B19751@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Jonathan Rosenberg'" , "'Brian Stucker'" , simple Subject: Re: [Simple] 200 vs. 202 References: <61D824C63B99D311975E00508B0CC98502C66C70@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii 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: Mon, 26 Nov 2001 16:21:20 -0500 Content-Transfer-Encoding: 7bit Is there something you are overlooking? I think so: I think you are overlooking the possibility that there are multiple subcription requests outstanding at the same time. And there are also implicit subscriptions generated in some cases. And of course there are also previously established subscriptions that continue to send notifies. Some of these may fork, and when that happens, you want to accept the stream of notifies from one of those forks. So how do you sort out which notifies to accept (because they are from distinct subscriptions or subsequent members of a series of notifications from a previously accepted source), and which should be refused because they they come from extra forks? According to draft-ietf-sip-events-00: 5.2.1. Correlation NOTIFY requests MUST contain the same Call-ID, local URI, and remote URI as the SUBSCRIBE request which ordered them. This is the same set of criteria that define a call leg. I believe this implies that something akin to a call leg (aka Dialog) be present. Paul adam.roach@ericsson.com wrote: > > That works, but it seems like a lot of extra implementation effort. > > There's really nothing magical about the dialog established by the > 200-class response to the SUBSCRIBE; it's just an arbitrary leg > which happens to have responded first. > > Given that fact, why don't we just change the scheme so that the > dialog associated with the SUBSCRIBE response isn't special, and > we just accept the first NOTIFY that arrives (and reject all the > other dialogs)? > > Is there something I'm overlooking? Accepting the first NOTIFY > seems much easier to implement than keeping track of dialogs that > will just need to be torn down. > > /a > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Wednesday, November 21, 2001 2:00 PM > > To: 'Brian Stucker'; adam.roach; simple > > Subject: RE: [Simple] 200 vs. 202 > > > > > > how about this: > > > > 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it > > accepts the > > NOTIFY > > 2. once the response to the SUBSCRIBE comes, if its not a > > match for the > > NOTIFY, the subscriber refreshes the dialog associated with > > the NOTIFY, but > > with Expires:0, to terminate it. > > > > This avoids the tight transaction timing interdependencies at > > the expense of > > some additional higher level processing. > > > > BTW, this is really a sip-events issue not so much a simple issue. > > > > -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: Wednesday, November 21, 2001 2:23 PM > > To: adam.roach; simple > > Subject: RE: [Simple] 200 vs. 202 > > > > > > You bring up an important point about the watcher having to > > wait for the > > response to the SUBSCRIBE before processing the NOTIFY. This > > could give us > > problems if the 200 takes a long time getting back to the > > watcher, and the > > NOTIFY, in the meantime, is just sitting there being > > retransmitted over and > > over, waiting for a response. Depending on the T1 and T2 > > timers being used, > > this could create a race condition that might cause a > > subscription to fail > > because there was no response to the immediate NOTIFY. > > In general, what happens when a NOTIFY to the inital > > SUBSCRIBE fails to be > > acknowledged? Does the subscription go away like it does for > > later NOTIFY > > messages? The reason I ask, is because it would seem to leave > > the watcher in > > an undefined state. What are the responsibilities of a > > watcher that sends a > > SUBSCRIBE, gets a 200, and then no NOTIFY? > > A possible solution would be to silently throw away and > > NOTIFY messages that > > we have not gotten a response (200) on the request to create > > a dialogue for > > (the SUBSCRIBE). If we do that, then we could wait for some > > period of time > > (say the expires header in the 200 response). If that period > > of time elapses > > without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). > > Thoughts? > > Brian > > -----Original Message----- > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > Sent: Tuesday, November 20, 2001 3:18 PM > > To: simple > > Subject: RE: [Simple] 200 vs. 202 > > > > > > While I disagree with Brian and Jonathan about the problems presented > > by having multiple PAs in the network, I am willing to quit the topic > > for the sake of moving forward. > > I am very wary, however, of any discussions which use arguments about > > the general case of forking of SUBSCRIBE requests instead of those > > involving multiple PAs. I wouldn't have even entered the fray if the > > arguments presented by several parties didn't attack the very notion > > of SUBSCRIBE forking (instead of limiting themselves to presence in > > particular). > > So, with my capitulation, I'll attempt to enumerate what I think > > we've all agreed on: > > 1. SUBSCRIBE requests may fork. > > 2. Subscribers may choose to accept zero or more of the > > NOTIFY requests that arrive by responding to them with > > a 200. > > 3. Subscribers may choose to reject zero or more of the > > NOTIFY requests that arrive by responding to them with > > a 481. > > 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I > > don't personally care which) accept exactly one NOTIFY > > message with a 200, and reject all others with a 481. > > 5. Subscribers _to_ _presence_ _information_ select which > > NOTIFY to accept based on the dialog information > > established by the 2xx response to the SUBSCRIBE. > > Moving forward, then, I see two sets of problems to be addressed: > > Forking SUBSCRIBE: > > - How do we perform authentication for forked SUBSCRIBE messages? > > This is actually a more general problem which can be phrased > > "How do we perform authentication for forked XXX messages?" where > > XXX includes INVITE. I would *really*, *really* like to see a > > more general solution to this problem before we start trying > > to cobble something together for SUBSCRIBE. > > - How do we protect against the DOS attacks that Robert describes? > > Presence: > > - In a forking situation, it is likely (probable, even) that the > > NOTIFY requests will arrive at the subscriber before the 2xx > > reply to the SUBSCRIBE. Does that mean that the response to the > > NOTIFY requests will be suppressed until the SUBSCRIBE request > > completes? If so, this should be well documented in the > > presence event package. > > - Some of the arguments made against accepting multiple dialogs > > created by a single SUBSCRIBE were privacy based: an aggregation > > point must exist in the network to provide a consistent policy. > > Given that there is no way to enforce that only one dialog is > > accepted, are there any privacy concerns that can arise from > > rogue clients accepting all received NOTIFYs? > > /a > > _______________________________________________ > > 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 Mon Nov 26 18:22:45 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11540 for ; Mon, 26 Nov 2001 18:22:38 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQNE97x006506; Mon, 26 Nov 2001 18:14:10 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03547; Mon, 26 Nov 2001 18:15:12 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03532 for ; Mon, 26 Nov 2001 18:14:00 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAQNDaT26971; Mon, 26 Nov 2001 18:13:37 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAE10004 (AUTH pkyzivat); Mon, 26 Nov 2001 18:14:55 -0500 (EST) Message-ID: <3C02CBE6.A1763730@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com, "'Jonathan Rosenberg'" , "'Brian Stucker'" , simple Subject: Re: [Simple] 200 vs. 202 References: <61D824C63B99D311975E00508B0CC98502C66C70@eamrcnt717.exu.ericsson.se> <3C02B250.65B19751@cisco.com> Content-Type: text/plain; charset=us-ascii 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: Mon, 26 Nov 2001 18:10:30 -0500 Content-Transfer-Encoding: 7bit I just noticed that I quoted from the obsolete draft-ietf-sip-events-00 rather than the newer draft-ietf-sip-events-01. The corresponding section there is different in detail, but (I think) similar in intent: 4.2.1. Correlation to dialogs, calls, and terminals ... Responses to SUBSCRIBE requests MUST contain a "tag" parameter in the "To" header. The "tag" in the "To" header allows the subscriber to differentiate between NOTIFY requests from different clients in the case that the SUBSCRIBE request was forked. You need to retain the tags from the subscribe in order to figure out what subscription a particular notify belongs to. Paul Paul Kyzivat wrote: > > Is there something you are overlooking? I think so: > > I think you are overlooking the possibility that there are multiple > subcription requests outstanding at the same time. And there are also > implicit subscriptions generated in some cases. And of course there are > also previously established subscriptions that continue to send > notifies. Some of these may fork, and when that happens, you want to > accept the stream of notifies from one of those forks. > > So how do you sort out which notifies to accept (because they are from > distinct subscriptions or subsequent members of a series of > notifications from a previously accepted source), and which should be > refused because they they come from extra forks? According to > draft-ietf-sip-events-00: > > 5.2.1. Correlation > > NOTIFY requests MUST contain the same Call-ID, local URI, and > remote URI as the SUBSCRIBE request which ordered them. This is > the same set of criteria that define a call leg. > > I believe this implies that something akin to a call leg (aka Dialog) be > present. > > Paul > > adam.roach@ericsson.com wrote: > > > > That works, but it seems like a lot of extra implementation effort. > > > > There's really nothing magical about the dialog established by the > > 200-class response to the SUBSCRIBE; it's just an arbitrary leg > > which happens to have responded first. > > > > Given that fact, why don't we just change the scheme so that the > > dialog associated with the SUBSCRIBE response isn't special, and > > we just accept the first NOTIFY that arrives (and reject all the > > other dialogs)? > > > > Is there something I'm overlooking? Accepting the first NOTIFY > > seems much easier to implement than keeping track of dialogs that > > will just need to be torn down. > > > > /a > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Wednesday, November 21, 2001 2:00 PM > > > To: 'Brian Stucker'; adam.roach; simple > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > how about this: > > > > > > 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it > > > accepts the > > > NOTIFY > > > 2. once the response to the SUBSCRIBE comes, if its not a > > > match for the > > > NOTIFY, the subscriber refreshes the dialog associated with > > > the NOTIFY, but > > > with Expires:0, to terminate it. > > > > > > This avoids the tight transaction timing interdependencies at > > > the expense of > > > some additional higher level processing. > > > > > > BTW, this is really a sip-events issue not so much a simple issue. > > > > > > -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: Wednesday, November 21, 2001 2:23 PM > > > To: adam.roach; simple > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > You bring up an important point about the watcher having to > > > wait for the > > > response to the SUBSCRIBE before processing the NOTIFY. This > > > could give us > > > problems if the 200 takes a long time getting back to the > > > watcher, and the > > > NOTIFY, in the meantime, is just sitting there being > > > retransmitted over and > > > over, waiting for a response. Depending on the T1 and T2 > > > timers being used, > > > this could create a race condition that might cause a > > > subscription to fail > > > because there was no response to the immediate NOTIFY. > > > In general, what happens when a NOTIFY to the inital > > > SUBSCRIBE fails to be > > > acknowledged? Does the subscription go away like it does for > > > later NOTIFY > > > messages? The reason I ask, is because it would seem to leave > > > the watcher in > > > an undefined state. What are the responsibilities of a > > > watcher that sends a > > > SUBSCRIBE, gets a 200, and then no NOTIFY? > > > A possible solution would be to silently throw away and > > > NOTIFY messages that > > > we have not gotten a response (200) on the request to create > > > a dialogue for > > > (the SUBSCRIBE). If we do that, then we could wait for some > > > period of time > > > (say the expires header in the 200 response). If that period > > > of time elapses > > > without a NOTIFY, then we send the SUBSCRIBE again (if we got a 200). > > > Thoughts? > > > Brian > > > -----Original Message----- > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > Sent: Tuesday, November 20, 2001 3:18 PM > > > To: simple > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > While I disagree with Brian and Jonathan about the problems presented > > > by having multiple PAs in the network, I am willing to quit the topic > > > for the sake of moving forward. > > > I am very wary, however, of any discussions which use arguments about > > > the general case of forking of SUBSCRIBE requests instead of those > > > involving multiple PAs. I wouldn't have even entered the fray if the > > > arguments presented by several parties didn't attack the very notion > > > of SUBSCRIBE forking (instead of limiting themselves to presence in > > > particular). > > > So, with my capitulation, I'll attempt to enumerate what I think > > > we've all agreed on: > > > 1. SUBSCRIBE requests may fork. > > > 2. Subscribers may choose to accept zero or more of the > > > NOTIFY requests that arrive by responding to them with > > > a 200. > > > 3. Subscribers may choose to reject zero or more of the > > > NOTIFY requests that arrive by responding to them with > > > a 481. > > > 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I > > > don't personally care which) accept exactly one NOTIFY > > > message with a 200, and reject all others with a 481. > > > 5. Subscribers _to_ _presence_ _information_ select which > > > NOTIFY to accept based on the dialog information > > > established by the 2xx response to the SUBSCRIBE. > > > Moving forward, then, I see two sets of problems to be addressed: > > > Forking SUBSCRIBE: > > > - How do we perform authentication for forked SUBSCRIBE messages? > > > This is actually a more general problem which can be phrased > > > "How do we perform authentication for forked XXX messages?" where > > > XXX includes INVITE. I would *really*, *really* like to see a > > > more general solution to this problem before we start trying > > > to cobble something together for SUBSCRIBE. > > > - How do we protect against the DOS attacks that Robert describes? > > > Presence: > > > - In a forking situation, it is likely (probable, even) that the > > > NOTIFY requests will arrive at the subscriber before the 2xx > > > reply to the SUBSCRIBE. Does that mean that the response to the > > > NOTIFY requests will be suppressed until the SUBSCRIBE request > > > completes? If so, this should be well documented in the > > > presence event package. > > > - Some of the arguments made against accepting multiple dialogs > > > created by a single SUBSCRIBE were privacy based: an aggregation > > > point must exist in the network to provide a consistent policy. > > > Given that there is no way to enforce that only one dialog is > > > accepted, are there any privacy concerns that can arise from > > > rogue clients accepting all received NOTIFYs? > > > /a > > > _______________________________________________ > > > 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 _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 18:45:28 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13048 for ; Mon, 26 Nov 2001 18:45:28 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAQNal7x006688; Mon, 26 Nov 2001 18:36:47 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03666; Mon, 26 Nov 2001 18:38:09 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03655 for ; Mon, 26 Nov 2001 18:37:06 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAQNajT27753; Mon, 26 Nov 2001 18:36:45 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAE10113 (AUTH pkyzivat); Mon, 26 Nov 2001 18:38:04 -0500 (EST) Message-ID: <3C02D153.76D1B38F@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Jonathan Rosenberg'" , "'Brian Stucker'" , simple Subject: Re: [Simple] 200 vs. 202 References: <61D824C63B99D311975E00508B0CC98502C66C7D@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii 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: Mon, 26 Nov 2001 18:33:39 -0500 Content-Transfer-Encoding: 7bit adam.roach@ericsson.com wrote: > > You might be surprised that, as the author of that draft, I was > aware of that fact. > > I'm sorry for not being sufficiently clear; I was trying to get > the general idea across, not crafting language for a specification. > > Of *course* I meant that you would accept the first NOTIFY > that could reasonably correspond to the pending SUBSCRIBE as being > the one dialog that gets established -- not just the first NOTIFY > that happened to float down the wire. > > /a Sorry if I was pointing out the obvious. But if you have to save state from the subscribe in order to decide what notify to accept, and if, once you accept a notify, you are going to establish a long lasting dialog and even refresh it periodically by sending new subscribe requests, do you save anything by not establishing the dialog as part of the initial subscription? Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 19:17:57 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15271 for ; Mon, 26 Nov 2001 19:17:57 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAR0FO7x006887; Mon, 26 Nov 2001 19:15:24 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03814; Mon, 26 Nov 2001 19:17:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03803 for ; Mon, 26 Nov 2001 19:16:49 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fAR0BHY25632; Mon, 26 Nov 2001 18:11:17 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAR0BGT27579; Mon, 26 Nov 2001 18:11:16 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id SAA09120; Mon, 26 Nov 2001 18:11:16 -0600 (CST) Reply-To: To: "'Paul Kyzivat'" , Cc: "'Jonathan Rosenberg'" , "'Brian Stucker'" , "simple" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C7F@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3C02D153.76D1B38F@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 26 Nov 2001 18:11:15 -0600 Content-Transfer-Encoding: 7bit > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sorry if I was pointing out the obvious. > > But if you have to save state from the subscribe in order to > decide what > notify to accept, and if, once you accept a notify, you are going to > establish a long lasting dialog and even refresh it periodically by > sending new subscribe requests, do you save anything by not > establishing > the dialog as part of the initial subscription? The issue being discussed is that the NOTIFY can arrive before the response to the SUBSCRIBE. In fact, if the SUBSCRIBE is forked, this is the most common scenario. One of my early (strawman) proposals was to wait until the SUBSCRIBE completed before responding to the NOTIFY. This is really rather complex to implement correctly. An improvement on this scheme was proposed by Jonathan: accept the NOTIFYs that arrive while the SUBSCRIBE is pending, and then un-subscribe to any that do not match the SUBSCRIBE response. After some analysis, I determined that this could probably be simplified (from an implementation point of view) further by simply accepting the first NOTIFY that could reasonably belong to the pending SUBSCRIBE, and reject the rest with 481s. The logic behind this simplification is that the SUBSCRIBE response isn't special; it just represents the response that happened to race to the forking proxy the fastest. It's not "better" than any of the other potential dialogs in any way. Sorry for continuing this discussion on the SIMPLE list; as Jonathan has pointed out a couple of times, this really has turned more into a sip-events issue than a SIMPLE issue. /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Mon Nov 26 19:28:08 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15806 for ; Mon, 26 Nov 2001 19:28:07 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAR0PL7x006961; Mon, 26 Nov 2001 19:25:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03869; Mon, 26 Nov 2001 19:27:09 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03858 for ; Mon, 26 Nov 2001 19:26:49 -0500 (EST) From: adam.roach@ericsson.com Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id fAQNOfH21337; Mon, 26 Nov 2001 17:24:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id fAQNOfT17967; Mon, 26 Nov 2001 17:24:41 -0600 (CST) Received: from pc050163 (pc050140.exu.ericsson.se [138.85.50.140]) by newman.exu.ericsson.se (8.7.5/8.7.3) with SMTP id RAA04919; Mon, 26 Nov 2001 17:24:40 -0600 (CST) Reply-To: To: "'Paul Kyzivat'" , , "'Jonathan Rosenberg'" , "'Brian Stucker'" , "simple" Subject: RE: [Simple] 200 vs. 202 Message-ID: <61D824C63B99D311975E00508B0CC98502C66C7D@eamrcnt717.exu.ericsson.se> 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 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <3C02CBE6.A1763730@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 26 Nov 2001 17:24:38 -0600 Content-Transfer-Encoding: 7bit You might be surprised that, as the author of that draft, I was aware of that fact. I'm sorry for not being sufficiently clear; I was trying to get the general idea across, not crafting language for a specification. Of *course* I meant that you would accept the first NOTIFY that could reasonably correspond to the pending SUBSCRIBE as being the one dialog that gets established -- not just the first NOTIFY that happened to float down the wire. /a > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, November 26, 2001 5:11 PM > To: adam.roach@ericsson.com; 'Jonathan Rosenberg'; 'Brian Stucker'; > simple > Subject: Re: [Simple] 200 vs. 202 > > > I just noticed that I quoted from the obsolete > draft-ietf-sip-events-00 > rather than the newer draft-ietf-sip-events-01. The corresponding > section there is different in detail, but (I think) similar in intent: > > 4.2.1. Correlation to dialogs, calls, and terminals > > ... Responses to SUBSCRIBE requests MUST contain a "tag" > parameter in the "To" header. > > The "tag" in the "To" header allows the subscriber to > differentiate between NOTIFY requests from different clients in > the case that the SUBSCRIBE request was forked. > > You need to retain the tags from the subscribe in order to figure out > what subscription a particular notify belongs to. > > Paul > > Paul Kyzivat wrote: > > > > Is there something you are overlooking? I think so: > > > > I think you are overlooking the possibility that there are multiple > > subcription requests outstanding at the same time. And > there are also > > implicit subscriptions generated in some cases. And of > course there are > > also previously established subscriptions that continue to send > > notifies. Some of these may fork, and when that happens, you want to > > accept the stream of notifies from one of those forks. > > > > So how do you sort out which notifies to accept (because > they are from > > distinct subscriptions or subsequent members of a series of > > notifications from a previously accepted source), and which > should be > > refused because they they come from extra forks? According to > > draft-ietf-sip-events-00: > > > > 5.2.1. Correlation > > > > NOTIFY requests MUST contain the same Call-ID, local URI, and > > remote URI as the SUBSCRIBE request which ordered them. This is > > the same set of criteria that define a call leg. > > > > I believe this implies that something akin to a call leg > (aka Dialog) be > > present. > > > > Paul > > > > adam.roach@ericsson.com wrote: > > > > > > That works, but it seems like a lot of extra > implementation effort. > > > > > > There's really nothing magical about the dialog established by the > > > 200-class response to the SUBSCRIBE; it's just an arbitrary leg > > > which happens to have responded first. > > > > > > Given that fact, why don't we just change the scheme so that the > > > dialog associated with the SUBSCRIBE response isn't special, and > > > we just accept the first NOTIFY that arrives (and reject all the > > > other dialogs)? > > > > > > Is there something I'm overlooking? Accepting the first NOTIFY > > > seems much easier to implement than keeping track of dialogs that > > > will just need to be torn down. > > > > > > /a > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Wednesday, November 21, 2001 2:00 PM > > > > To: 'Brian Stucker'; adam.roach; simple > > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > > > > how about this: > > > > > > > > 1. if the subscriber hasn't gotten a 2xx to the SUBSCRIBE, it > > > > accepts the > > > > NOTIFY > > > > 2. once the response to the SUBSCRIBE comes, if its not a > > > > match for the > > > > NOTIFY, the subscriber refreshes the dialog associated with > > > > the NOTIFY, but > > > > with Expires:0, to terminate it. > > > > > > > > This avoids the tight transaction timing interdependencies at > > > > the expense of > > > > some additional higher level processing. > > > > > > > > BTW, this is really a sip-events issue not so much a > simple issue. > > > > > > > > -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: Wednesday, November 21, 2001 2:23 PM > > > > To: adam.roach; simple > > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > > > > You bring up an important point about the watcher having to > > > > wait for the > > > > response to the SUBSCRIBE before processing the NOTIFY. This > > > > could give us > > > > problems if the 200 takes a long time getting back to the > > > > watcher, and the > > > > NOTIFY, in the meantime, is just sitting there being > > > > retransmitted over and > > > > over, waiting for a response. Depending on the T1 and T2 > > > > timers being used, > > > > this could create a race condition that might cause a > > > > subscription to fail > > > > because there was no response to the immediate NOTIFY. > > > > In general, what happens when a NOTIFY to the inital > > > > SUBSCRIBE fails to be > > > > acknowledged? Does the subscription go away like it does for > > > > later NOTIFY > > > > messages? The reason I ask, is because it would seem to leave > > > > the watcher in > > > > an undefined state. What are the responsibilities of a > > > > watcher that sends a > > > > SUBSCRIBE, gets a 200, and then no NOTIFY? > > > > A possible solution would be to silently throw away and > > > > NOTIFY messages that > > > > we have not gotten a response (200) on the request to create > > > > a dialogue for > > > > (the SUBSCRIBE). If we do that, then we could wait for some > > > > period of time > > > > (say the expires header in the 200 response). If that period > > > > of time elapses > > > > without a NOTIFY, then we send the SUBSCRIBE again (if > we got a 200). > > > > Thoughts? > > > > Brian > > > > -----Original Message----- > > > > From: adam.roach@ericsson.com [mailto:adam.roach@ericsson.com] > > > > Sent: Tuesday, November 20, 2001 3:18 PM > > > > To: simple > > > > Subject: RE: [Simple] 200 vs. 202 > > > > > > > > > > > > While I disagree with Brian and Jonathan about the > problems presented > > > > by having multiple PAs in the network, I am willing to > quit the topic > > > > for the sake of moving forward. > > > > I am very wary, however, of any discussions which use > arguments about > > > > the general case of forking of SUBSCRIBE requests > instead of those > > > > involving multiple PAs. I wouldn't have even entered > the fray if the > > > > arguments presented by several parties didn't attack > the very notion > > > > of SUBSCRIBE forking (instead of limiting themselves to > presence in > > > > particular). > > > > So, with my capitulation, I'll attempt to enumerate what I think > > > > we've all agreed on: > > > > 1. SUBSCRIBE requests may fork. > > > > 2. Subscribers may choose to accept zero or more of the > > > > NOTIFY requests that arrive by responding to them with > > > > a 200. > > > > 3. Subscribers may choose to reject zero or more of the > > > > NOTIFY requests that arrive by responding to them with > > > > a 481. > > > > 4. Subscribers _to_ _presence_ _information_ SHOULD or MUST (I > > > > don't personally care which) accept exactly one NOTIFY > > > > message with a 200, and reject all others with a 481. > > > > 5. Subscribers _to_ _presence_ _information_ select which > > > > NOTIFY to accept based on the dialog information > > > > established by the 2xx response to the SUBSCRIBE. > > > > Moving forward, then, I see two sets of problems to be > addressed: > > > > Forking SUBSCRIBE: > > > > - How do we perform authentication for forked > SUBSCRIBE messages? > > > > This is actually a more general problem which can be phrased > > > > "How do we perform authentication for forked XXX > messages?" where > > > > XXX includes INVITE. I would *really*, *really* > like to see a > > > > more general solution to this problem before we start trying > > > > to cobble something together for SUBSCRIBE. > > > > - How do we protect against the DOS attacks that > Robert describes? > > > > Presence: > > > > - In a forking situation, it is likely (probable, > even) that the > > > > NOTIFY requests will arrive at the subscriber before the 2xx > > > > reply to the SUBSCRIBE. Does that mean that the > response to the > > > > NOTIFY requests will be suppressed until the > SUBSCRIBE request > > > > completes? If so, this should be well documented in the > > > > presence event package. > > > > - Some of the arguments made against accepting > multiple dialogs > > > > created by a single SUBSCRIBE were privacy based: > an aggregation > > > > point must exist in the network to provide a > consistent policy. > > > > Given that there is no way to enforce that only one > dialog is > > > > accepted, are there any privacy concerns that can arise from > > > > rogue clients accepting all received NOTIFYs? > > > > /a > > > > _______________________________________________ > > > > 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 > _______________________________________________ > 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 Tue Nov 27 03:21:10 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16082 for ; Tue, 27 Nov 2001 03:21:10 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAR8IX7x007965; Tue, 27 Nov 2001 03:18:34 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05311; Tue, 27 Nov 2001 03:20:14 -0500 (EST) Received: from mailrelay.bluelabs.se (mailrelay.bluelabs.se [194.17.38.34]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05293 for ; Tue, 27 Nov 2001 03:19:24 -0500 (EST) From: Hakan.Jonsson@bluelabs.se Received: from blnet-sth-vscan.bluelabs.se (blnet-sth-vscan1.bluelabs.se [194.17.38.247]) by mailrelay.bluelabs.se (Postfix) with SMTP id A5A3217CB for ; Tue, 27 Nov 2001 09:19:00 +0100 (CET) Received: FROM blue-sth1.bluelabs.se BY blnet-sth-vscan.bluelabs.se ; Tue Nov 27 09:18:58 2001 +0100 Subject: RE: [Simple] new I-D on subscribing to buddy lists To: Jonathan Rosenberg Cc: Ben Campbell , Jonathan Rosenberg , "'simple@mailman.dynamicsoft.com'" , simple-admin@mailman.dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: X-MIMETrack: Serialize by Router on Blue-sth1/srv/Bluelabs(Release 5.0.6a |January 17, 2001) at 2001-11-27 09:18:58 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.dynamicsoft.com id DAA05293 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, 27 Nov 2001 09:18:55 +0100 Content-Transfer-Encoding: 8bit >> > The latter could perhaps be used in some way to join >> subscriptions. Say >> > that I have made a SUBCRIBE request for the >> presence.delegate package and >> > later make a SUBSCRIBE request for an individual user, it >> would be very >> > useful to join the individual subscription to the delegated >> subscription. I >> > am not sure how though (yet). >> >> >> Wow, the thought makes my head hurt :-) I suspect any >> _protocol_ level >> solution to that would add a lot of complexity for a corner >> use case. I >> think that sort of thing is better left to individual implementation >> decisions. (Assuming an app could detect the condition, it could >> disallow the second subscription, or drop the presentity from the >> current buddy list subscription, etc.) > >I don't like the idea of states of subscriptions affecting each other. It >makes a lot more sense to keep these separate. Indeed, there may very well >be reasons why a client wishes to have a group and an individual >subscription separately. You don't want the server to make assumptions about >what the client is trying to achieve. Sorry for not being very clear. I just wanted the client to have the possibility to request the joining of a presence subscription with a presence.aggregate subscription, not an enforcement or guesswork from the server. To use aggregate subscriptions, the client now has to update the buddylist in some undefined way (if using SIP) from which the aggregate subscription is generated, and then refresh it, get some undefined authorization result back, in some undefined format (if using SIP). I would prefer letting the client be able to arrange the subscription first, and then join it with the aggregate. Does it make sense or am I just rambling? Regards, Håkan _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 27 04:04:52 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17020 for ; Tue, 27 Nov 2001 04:04:52 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAR92N7x008097; Tue, 27 Nov 2001 04:02:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05481; Tue, 27 Nov 2001 04:04:09 -0500 (EST) Received: from pine.il.neustar.com (pine.neustar.com [209.173.57.70]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05469 for ; Tue, 27 Nov 2001 04:03:37 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.il.neustar.com (8.11.0/8.11.0) with ESMTP id fAR93DJ01927; Tue, 27 Nov 2001 03:03:13 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 03:05:39 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAC87@va02.va.neustar.com> From: "Peterson, Jon" To: "'Roy, Radhika R, ALCTA'" , mankin@isi.edu Cc: simple MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Guidelines for IM Sessions 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, 27 Nov 2001 03:05:27 -0600 On the first question, while I imagine "integration" would need to be elaborated a bit, I think a general requirement along these lines is appropriate for the SIMPLE WG - but I'm not immediately sure how it factors in with the topic of this particular draft, which largely concerns congestional control and the effects of intermediaries on the transport of messages. A small amount of effort has been made in the draft to generalize these problems to be applicable other IM efforts than SIMPLE - I don't think that multimedia integration is necessarily an appropriate requirement for all IM systems. The second question is more complicated. There are no doubt a number of potential congestion control issues that must be considered in a presence system. Of especial interest in SIMPLE are matters concerning how well networks using the SIP events mechanism will scale, for example how frequently signaling traffic (like NOTIFYs) should go directly end-to-end rather than through intermediaries, and so forth. The draft that Allison and I wrote arose because a new model for IM (this chat/session model in contrast to the paging model) had developed in the WG - a situation where new protocols were being proposed, or existing protocols applied to new architectures, and Allison felt that some guidelines were in order. For the presence case, though, the properties of SIP as a signaling protocol (as it would apply to the SIP events mechanism) with regards to congestion control are comparatively well understood and have been worked into the charter from the start of this WG. If any issues with the scalability of the SIP events mechanism are uncovered in the exploration of the presence event package, these issues would probably best be raised in the SIP WG. So in short, I see no immediate need for a draft on the subject - but you are definitely correct that we need to be mindful of the implications of congestion and intermediaries to the presence work. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, November 26, 2001 12:35 PM > To: mankin@isi.edu; Jon.Peterson@NeuStar.com > Cc: simple > Subject: I-D: Guidelines for IM Sessions > > > Hi, Allison and Jon: > > The draft for "Guidelines for IM and Presence > is an excellent one. > It provides us > clear pictures how the standards need to be developed and > what issues need > to be addressed that are not usually apparent to many of us. > > I have two requests as follows: > > 1. Can we include a statement in "Normative Guidelines" > section that IM > sessions can also be integrated with audio and/or video > sessions (or similar > statement), if needed? > > 2. Can we expect a similar draft for "Presence" as well? > > Best regards, > > Radhika R. Roy > rrroy@att.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 27 08:45:22 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26757 for ; Tue, 27 Nov 2001 08:45:21 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARDgb7x008839; Tue, 27 Nov 2001 08:42:38 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06397; Tue, 27 Nov 2001 08:44:09 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06386 for ; Tue, 27 Nov 2001 08:43:05 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fARDghT17589; Tue, 27 Nov 2001 08:42:43 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAE11628 (AUTH pkyzivat); Tue, 27 Nov 2001 08:44:03 -0500 (EST) Message-ID: <3C039797.C13A45B6@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: adam.roach@ericsson.com CC: "'Jonathan Rosenberg'" , "'Brian Stucker'" , simple Subject: Re: [Simple] 200 vs. 202 References: <61D824C63B99D311975E00508B0CC98502C66C7F@eamrcnt717.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii 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: Tue, 27 Nov 2001 08:39:35 -0500 Content-Transfer-Encoding: 7bit OK. Thanks for the tutorial - I think I get it now. But, all the complexity and loose ends suggests to me that there is something fundamentally wrong with the mechanism here. As you say, this is really an events issue, not a SIMPLE issue. Paul adam.roach@ericsson.com wrote: > > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > > > Sorry if I was pointing out the obvious. > > > > But if you have to save state from the subscribe in order to > > decide what > > notify to accept, and if, once you accept a notify, you are going to > > establish a long lasting dialog and even refresh it periodically by > > sending new subscribe requests, do you save anything by not > > establishing > > the dialog as part of the initial subscription? > > The issue being discussed is that the NOTIFY can arrive > before the response to the SUBSCRIBE. In fact, if the > SUBSCRIBE is forked, this is the most common scenario. > > One of my early (strawman) proposals was to wait until the > SUBSCRIBE completed before responding to the NOTIFY. This > is really rather complex to implement correctly. > > An improvement on this scheme was proposed by Jonathan: > accept the NOTIFYs that arrive while the SUBSCRIBE is > pending, and then un-subscribe to any that do not match > the SUBSCRIBE response. > > After some analysis, I determined that this could > probably be simplified (from an implementation point of view) > further by simply accepting the first NOTIFY that could > reasonably belong to the pending SUBSCRIBE, and reject the > rest with 481s. The logic behind this simplification is > that the SUBSCRIBE response isn't special; it just represents > the response that happened to race to the forking proxy > the fastest. It's not "better" than any of the other > potential dialogs in any way. > > Sorry for continuing this discussion on the SIMPLE list; > as Jonathan has pointed out a couple of times, this really > has turned more into a sip-events issue than a SIMPLE issue. > > /a _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 27 10:47:55 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04706 for ; Tue, 27 Nov 2001 10:47:55 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARFjP7x009647; Tue, 27 Nov 2001 10:45:25 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06799; Tue, 27 Nov 2001 10:47:12 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06788 for ; Tue, 27 Nov 2001 10:46:43 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fARFkAD02305; Tue, 27 Nov 2001 10:46:11 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA27538; Tue, 27 Nov 2001 10:44:45 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 10:46:04 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F958C047@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: "Peterson, Jon" , mankin@isi.edu Cc: simple MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: Guidelines for IM Sessions 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, 27 Nov 2001 10:45:53 -0500 Hi, Jon: I agree with you. I do not know whether I have been clear in explaining my points. Let me try again: 1. IM and Audio/Video Session Model in SIP We have audio/video session model in SIP. Now we have IM session model using SIP. (We know that the paging model is a different one - a special case). The implication is that there should be a conformity between audio/video and IM session model while people will be using SIP. If this point is added in the guideline, it would have been better. 2. Guidelines in Presence There may be some issues related to scalability and others in Presence as well. I am wondering whether any guidelines can also be provided in Presence. Radhika R. Roy rrroy@att.com -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, November 27, 2001 4:05 AM To: Roy, Radhika R, ALCTA; mankin@isi.edu Cc: simple Subject: RE: Guidelines for IM Sessions On the first question, while I imagine "integration" would need to be elaborated a bit, I think a general requirement along these lines is appropriate for the SIMPLE WG - but I'm not immediately sure how it factors in with the topic of this particular draft, which largely concerns congestional control and the effects of intermediaries on the transport of messages. A small amount of effort has been made in the draft to generalize these problems to be applicable other IM efforts than SIMPLE - I don't think that multimedia integration is necessarily an appropriate requirement for all IM systems. The second question is more complicated. There are no doubt a number of potential congestion control issues that must be considered in a presence system. Of especial interest in SIMPLE are matters concerning how well networks using the SIP events mechanism will scale, for example how frequently signaling traffic (like NOTIFYs) should go directly end-to-end rather than through intermediaries, and so forth. The draft that Allison and I wrote arose because a new model for IM (this chat/session model in contrast to the paging model) had developed in the WG - a situation where new protocols were being proposed, or existing protocols applied to new architectures, and Allison felt that some guidelines were in order. For the presence case, though, the properties of SIP as a signaling protocol (as it would apply to the SIP events mechanism) with regards to congestion control are comparatively well understood and have been worked into the charter from the start of this WG. If any issues with the scalability of the SIP events mechanism are uncovered in the exploration of the presence event package, these issues would probably best be raised in the SIP WG. So in short, I see no immediate need for a draft on the subject - but you are definitely correct that we need to be mindful of the implications of congestion and intermediaries to the presence work. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, November 26, 2001 12:35 PM > To: mankin@isi.edu; Jon.Peterson@NeuStar.com > Cc: simple > Subject: I-D: Guidelines for IM Sessions > > > Hi, Allison and Jon: > > The draft for "Guidelines for IM and Presence > is an excellent one. > It provides us > clear pictures how the standards need to be developed and > what issues need > to be addressed that are not usually apparent to many of us. > > I have two requests as follows: > > 1. Can we include a statement in "Normative Guidelines" > section that IM > sessions can also be integrated with audio and/or video > sessions (or similar > statement), if needed? > > 2. Can we expect a similar draft for "Presence" as well? > > Best regards, > > Radhika R. Roy > rrroy@att.com > _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Tue Nov 27 17:52:23 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28455 for ; Tue, 27 Nov 2001 17:52:23 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fARMnM7x013376; Tue, 27 Nov 2001 17:49:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08150; Tue, 27 Nov 2001 17:51:09 -0500 (EST) Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08139 for ; Tue, 27 Nov 2001 17:50:54 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23500; Tue, 27 Nov 2001 17:50:28 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19106; Tue, 27 Nov 2001 17:50:29 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 27 Nov 2001 17:50:29 -0500 Message-ID: <313680C9A886D511A06000204840E1CF57C5B2@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Theodore Havinis'" Cc: simple@mailman.dynamicsoft.com Subject: RE: [Simple] RE: Buddy list per User per Event service associatio n ??? 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: Tue, 27 Nov 2001 17:50:28 -0500 The problem is that many people have a view based on the current implementations of buddy lists that such a list is on the watcher side, and not on the presentity side. Nothing prevents you from making an implementation that adds a buddy to the presentity's buddy list (who he watches) as a consequence of some operation like authorizing subscriptions to presence information. If users like that implementation, you may become famous. I find the current implementations intuitively correct - I decide who I care to watch, and just because you want to see my presence does not mean I want to see yours. YMMV. Brian > -----Original Message----- > From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > Sent: Friday, November 23, 2001 10:05 AM > To: Rosen, Brian > Cc: simple@mailman.dynamicsoft.com > Subject: RE: [Simple] RE: Buddy list per User per Event service > association ??? > > > > > I find it confusing taklking about buddies "one way only". > I think whether I join a buddy list or I allow somebody to join > my buddy list, if the application decides to put the 2 together, > as far as i see it is part of the same buddy list. > > The determining factor should not be who initiates the SUBSCRIBE, > but it should the 'authorization'. > > Theodore > > >-----Original Message----- > >From: simple-admin@mailman.dynamicsoft.com > >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of > Rosen, Brian > >Sent: Wednesday, November 21, 2001 10:38 AM > >To: 'Theodore Havinis' > >Cc: 'simple@mailman.dynamicsoft.com' > >Subject: RE: [Simple] RE: Buddy list per User per Event service > >association ??? > > > > > >And, it's a race to see who types the fastest..... > > > >The guy with the buddy list is John, not Bob. John has a list > >of buddies he sees presence for. If he wants to add Bob to his > >list, then he has to subscribe to Bob's presence, and indeed, > >Bob can decide to not let him do that. > > > >The point of the buddy list is when John logs on for the > >umpteenth time, instead of again subscribing to John, and Mary, > >and Fred, and Joe individually, he does one operation (subscribe > >my buddy list), and all the individual subscription actions > >are performed on John's behalf. If any of them failed, that > >"buddy" would not show presence to John. > > > >Bob may have his own buddy list, but it has the people Bob wants > >to see presence for. > > > >So buddy lists are for watchers. Presentities may have lists of > >authorized subscribers, or they may have more complex rules. So > >far, that is beyond our specification work. AFAIK, a buddy list > >is really just a shorthand equivalent to a bunch of individual > >subscriptions. As Jonathan notes, this duplicates what is in AIM > >or other commercial IM systems. In those systems, each of the > >buddy lists are watchers. Of course, nothing prevents Bob from > >being in John's buddy list, but that is up to John. It is up to > >Bob to decide if he will let John see his presence information, > >or, more precisely, what he will let him see, since it isn't binary. > > > >Brian > > > >> -----Original Message----- > >> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > >> Sent: Wednesday, November 21, 2001 11:44 AM > >> To: Jonathan Rosenberg > >> Cc: simple@mailman.dynamicsoft.com > >> Subject: RE: [Simple] RE: Buddy list per User per Event service > >> association ??? > >> > >> > >> > >> Hi Jonathan, > >> > >> Thanks for your comments. > >> > >> Please find my comments below. > >> > >> Kind Rgds > >> Theo > >> > >> >-----Original Message----- > >> >From: simple-admin@mailman.dynamicsoft.com > >> >[mailto:simple-admin@mailman.dynamicsoft.com]On Behalf Of Jonathan > >> >Rosenberg > >> >Sent: Tuesday, November 20, 2001 10:48 PM > >> >To: 'Theodore Havinis'; Jonathan Rosenberg > >> >Cc: simple@mailman.dynamicsoft.com > >> >Subject: [Simple] RE: Buddy list per User per Event service > >> association > >> >??? > >> > > >> > > >> > > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Theodore Havinis [mailto:theodore.havinis@openwave.com] > >> >> Sent: Tuesday, November 20, 2001 5:38 PM > >> >> To: Jonathan Rosenberg > >> >> Cc: simple@mailman.dynamicsoft.com > >> >> Subject: Buddy list per User per Event service association ??? > >> >> > >> >> I have two questions for clarifications. I'd appreciate > >> your feedback. > >> >> > >> >> Clarification-I: Is it possible with the model you > >> describe to build a > >> >> buddy-list tree > >> >> whereby each User has separate buddy lists for separate > services ie > >> >> effectively a buddy list > >> >> for telephony buddies (ie buddies who want to subscribe to > >> >> his telephony > >> >> event), a separate > >> >> one for IM buddies, or even distinguish between a buddy list > >> >> for 'business > >> >> telephony > >> >> buddies' and a buddy list for 'family telephony buddies'. > >> > > >> >Of course. A buddy list is just a named resource. I can > >> subscribe to any > >> >named resource - sip:friends@foo.com, sip:family@foo.com, > >> etc., so long as > >> >those resources are defined. > >> > > >> >> > >> >> Example: A user gets a subscription from an operator for > >> >> telephony service, > >> >> IM service, Voice Mail service etc. > >> >> and he would like to build the following scenario that > >> reach him via > >> >> telephony you should become part of his > >> >> telephony-buddies, for as long as needed ie just for the > >> >> duration of the > >> >> call or longer. > >> >> > >> >> > >> >> IM event Telephony event > >> >> VoiceMail > >> >> event > >> >> |-----------| |--------------|------------| > >> >> |---------------| > >> >> | | | | | > | > >> >> | > >> >> fam.BLSS buz.BLSS fam.BLSS friend.BLSS buz.BLSS > >> >> friends.BLSS buz.BLSS > >> >> > >> >> The sum of BLSS's is the User's BLSS which resides with his > >> >> home operator or > >> >> 3rd party-provider. > >> > > >> >I'm afraid you've lost me here. Just to be clear we are > >> talking about the > >> >same thing - my buddy list is the set of people I want to > >> learn presence > >> >about. In existing systems, this is the list of names you > >> see on your own > >> >messenger tool. Rather than subscribing to each one > >> individually, I can > >> >subscribe to sip:mybuddies@foo.com, and the server handling > >> >mybuddies@foo.com generates subscriptions for all the users > >> in my list. > >> > >> I didn't mean it differently. > >> > > >> > >> So what I was trying to understand is 'where we going' > when combining > >> Events, Buddy Lists, > >> Wacher lists since these drafts can be very powerful in > some ways when > >> combined. > >> > >> So here is an example of what I was trying to say in my > >> previous email. > >> > >> Lets assume that John decides to call Bob for the first time. > >> One way to provide certain screening services on behalf of > >> Bob for the call > >> he is receiving from John > >> is to have John first SUBSCRIBE to the Bob's authorized buddy > >> list for the > >> telephony event. > >> So, as soon as John tries to SUBSCRIBE to Bob's "call event > >> buddy list" > >> Bob gets notified that John wants to SUBSCRIBE to him. Bob > >> has a number of > >> choices: > >> (a) reject the subscription > >> (b) allow John to talk to Bob without allowing him joining > >> Bob's call event > >> buddy list > >> (c) allow Jonh to talk to Bob, and at the same time, let him > >> join Bob's call > >> event buddy list > >> > >> If Bob allows the subscription of John to his telephony > >> event, then John > >> joins Bob's > >> buddy list for telephony. Next time John calls Bob, John is > >> already a buddy > >> of his > >> for the telephony event, thus getting authorized and the call gets > >> established (assuming no other restrictions) > >> > >> What I describe above for the call event, can be applied to any > >> communication mean such as IM etc. > >> > >> I was wondering if this one way of how we envision to make > >> use of Events, > >> Buddy lists in future in order > >> to give more control to a Callee's communication. > >> > >> > >> >> > >> >> So, is that possible to be done when combining buddy-lists, > >> >> events etc. > >> >> based on the buddy-list draft and on the > >> >> event draft from Adam R. and also should all these events and > >> >> buddy lists be > >> >> registered with IANA ??? > >> > > >> >You wouldn't IANA register buddy lists any more than you would > >> >IANA register > >> >user names. > >> > > >> >> > >> >> Clarification-II: > >> >> I believe it would be good if you could explain the > >> >> connection between the > >> >> 'watcherinfo' draft and this draft. > >> >> In my understanding with the watcherinfo one can start > >> >> creating buddy lists > >> >> as well, ie allow those watchers requesting > >> >> my presence information to subscribe to my presence. > >> > > >> >They are basically comverses of each other: > >> > > >> >A buddy list is the set of people I want to subscribe to > >> (i.e., the set of > >> >people whose presence I want to learn) > >> > > >> >The watcher list is the set of people who want to subscribe > >> to me (which > >> >includes those that have successfully subscribed and those > >> who are merely > >> >pending). > >> > > >> >Both are lists, but represent different entities. A buddy > >> list benefits a > >> >subscriber, a watcher list is for a presentity. > >> > > >> >I can set up authorization policy as a list that contains > >> those folks that > >> >are allowed to subscribe to me. Call this the "authorized > >> watcher list". It > >> >may so happen that my authorized watcher list is the same as > >> my buddy list, > >> >but that is not necessary; these are fundamentally different lists > >> >as far as > >> >the protocol/architecture is concerned. > >> > >> > >> They may be the same for a > >> >particular deployment of a real service, but thats a > separate matter. > >> > >> Thanks, it helped. > >> So, I have a buddy list, with buddies who subscribed to > >> my call event, and my call event buddy list gets updated > >> (through a watcher > >> client) about > >> my buddies presence, so I know who is available to be called > >> and who isn't > >> because they > >> appear to be as offline. > >> Does that make sense ? > >> > >> > >> Thanks > >> /Theo > >> > >> > > >> >-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 > >> > >_______________________________________________ > >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 Nov 28 00:39:33 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08459 for ; Wed, 28 Nov 2001 00:39:33 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAS5aM7x014509; Wed, 28 Nov 2001 00:36:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09367; Wed, 28 Nov 2001 00:38:09 -0500 (EST) 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 AAA09355 for ; Wed, 28 Nov 2001 00:37:42 -0500 (EST) 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 fAS5Zq7x014504; Wed, 28 Nov 2001 00:35:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 00:37:18 -0500 Message-ID: From: Jonathan Rosenberg To: "'Paul Kyzivat'" , Jonathan Rosenberg Cc: "'sip@ietf.org'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: RE: [Simple] New I-D on IM transport 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: Wed, 28 Nov 2001 00:37:18 -0500 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, November 26, 2001 1:45 PM > To: Jonathan Rosenberg > Cc: 'sip@ietf.org'; Ben Campbell; simple@mailman.dynamicsoft.com > Subject: Re: [Simple] New I-D on IM transport > > > Jonathan Rosenberg wrote: > > > > Indeed. I have in fact written a draft on doing just that: > > > > > http://www.jdrosen.net/papers/draft-rosenberg-sip-reconstitute-00.txt > > Intesting paper. I think that a procedure of this sort is definitely > needed. There is very little in here that needs to be standardized; since it is something that effects baseline operation (it defines a failure scenario that is not defined), it is my hope to incorporate the baseline stuff into bis. Thats currently an open issue we're tracking. > > Here are some specific comments/questions about the details > of what you > propose: > > - what if the problem wasn't with the endpoint at all, but > rather was an > intermittent problem with the network? In that case, both ends may try > to initiate recovery. (The analogy in the PSTN is the > familiar "we were > disconnected, but when I tried to call back your line was busy" > problem.) No problem. If both sides send at the same time, the glare procedures will handle that. If its sequential, its sequential. I think the draft talks about giving up if the reinvite doesn't help after a few tries. > > - what if there is no problem with signalling but there is a problem > with the media stream? Then the reinvite will reach the original > endpoint rather than a backup. It will not be able to distinguish this > reinvite from one for some other purpose, like session timer > refresh. It > will note that the sdp has not changed, and may choose to > simply return > the last sdp it sent. (This could happen if the sip and media > travel on > different network connections to the same host, or if the > media is on a > separate device with its own network connection.) I guess this seems to me to be the right behavior. What would you want to happen in this case? > > - your 3pcc example requires that the controller forward on all > reinvites, even if nothing in the sdp has changed. However there are > other cases where this is a bad thing. There may well be > reinvites going > on simply to update session timers. Since the session timer > schedule may > differ on the two legs, it isn't desirable to forward noop invites. I don't think a controller will ever be in a position to adequately determine what really constitutes a no-op re-invite, and should therefore pass along everything, even if it means faster session timers on both ends of a call (the session timer is infrequent anyway). > > - in a separate mail thread on the comedia draft, we identified some > added problems with reinvites and connection oriented media. In that > case, what is negotiated in the sdp is used to establish a media > connection, so it isn't idempotent to subsequent invitations. There is > need to indicate in the sdp whether to renegotiate the connection or > not. I don't think we ever fully resolved that. But I believe it is > important that something in the sdp be changed to indicate a desire to > renegotiate the connection. The same kind of scenario applies here. This is a good point. I think its a pure co-media issue, though, and that needs to be addressed in that draft. > > All of these issues suggest to me that some explicit information needs > to be conveyed indicating what is being attempted. Part of > this might be > a Reason header indicating that the reinvite is being sent to recover > from a perceived problem. I'm still not convinced, so long as the comedia issue is handled. -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 Nov 28 01:18:02 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09824 for ; Wed, 28 Nov 2001 01:18:01 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAS6FQ7x014665; Wed, 28 Nov 2001 01:15:26 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09504; Wed, 28 Nov 2001 01:17:10 -0500 (EST) 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 BAA09493 for ; Wed, 28 Nov 2001 01:16:54 -0500 (EST) 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 AAA19213 for ; Wed, 28 Nov 2001 00:16:29 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 28 Nov 2001 00:11:50 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 00:15:15 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EF528DA@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Jonathan Rosenberg , "'Michael Hammer'" Cc: "'adam.roach@ericsson.com'" , simple , "Alex Nava" , "Patrick Sollee" , "Sanjoy Sen" Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C177D4.0A2BCFA0" 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, 28 Nov 2001 00:15:13 -0600 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_01C177D4.0A2BCFA0 Content-Type: text/plain; charset="iso-8859-1" Good idea (HTTP url)... The thought had occurred to me briefly, but I really hadn't thought it out much. Actually, would it be possible to simply throw a request URI into a presence notification for any sort of a transfer? i.e. to get around problems with message length and firewall/NAT issues, is it important that we actually include the cpim-xpidf+xml document in the NOTIFY, or could we simply add that you might get an application/cpim-xpidf-url document, that the client can go grab using HTTP. Solves all of the problems in one tidy package. That way clients initiate the transfer of the presence document, and can choose TCP if they wish (likely), or if they suspect they're behind a firewall/NAT. When they make the subscription, they could include an accept with the application/cpim-xpidf-url content type which would simply be an HTTP or HTTPS url to where to grab the presence document. Another added advantage would be that you could use a "cheap" transport like UDP to send the notification, and then let the client initiate an "expensive" transport like TCP or TLS, on demand, to go get the document when it needs to. That would allow established secure HTTP transfers to take place when retrieving the data that we're trying to pull. We could stipulate that the document that the HTTP url points to must be an application/cpim-xpidf+xml formatted document. Regards, Brian Stucker Nortel Networks -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Monday, November 26, 2001 2:03 PM To: 'Michael Hammer'; Jonathan Rosenberg Cc: 'adam.roach@ericsson.com'; Stucker, Brian [NGB:B635:EXCH]; simple; Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick [NGC:B680:EXCH]; Sen, Sanjoy [NGB:B692:EXCH] Subject: RE: [Simple] RE: Question regarding NOTIFY messages using UDP. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Wednesday, November 21, 2001 10:11 AM > To: Jonathan Rosenberg > Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; simple; Alex Nava; > Patrick Sollee; Sanjoy Sen > Subject: RE: [Simple] RE: Question regarding NOTIFY messages > using UDP. > > > Jonathan, > > While not favoring any fragmentation mechanism for SIP, does > this preclude > any implementation (higher level application using SIP) from > choosing to > send the body of the Notifies as incremental parts? It would > seem that the > SIP-level mechanisms would be unaware of the full nature of > the body which > it carries and should place no restrictions on that body. > > That is, it provides no mechanism nor precludes use of such a > mechanism. The spec assumes full-state, and talks about using CSeq to determine the most recent document, which wouldn't make sense for partial documents as you have described. An extension could in principle override this, and you could define a document format that supports partial information. However, I still assert that: 1. this is a problem in theory only 2. if the docs do become large, delta encoding is better Honestly, the problem is more for other event packages that may convey larger amounts of state. Brian later writes: > Ok, here's a thought... > If we're in a position where we think we're going to need to use TCP (or some other > connection-oriented protocol) to notify the watcher (in this example, a presence > subscriber), but it's difficult to keep up a bunch of TCP connections, we use the > following general mechanism. > > 1. We send the watcher a NOTIFY that says in effect "you need to fetch the current state > of this resource" (in this case, probably using UDP). > > 2. The watcher responds to the NOTIFY with a 200 OK however it chooses. > > 3. The watcher sends a SUBSCRIBE in to fetch the current state of the resource (in this > case a presentity) using the transport of it's choosing. If it knows it's behind a > firewall, or a NAT, then it can pick TCP, for instance. Actually, we've been toying with the idea of not even using SUBSCRIBE for this. An HTTP request is just fine for synchronously fetching a document; thats what its designed to do. One could think of this as another sub-package, say "alert". If you subscribe to foo.alert, you get a NOTIFY when foo changes, but the NOTIFY contains a body type that is always short - providing a URL for actually retrieving the thing that has changed. In fact, the default could be as simple as application/uri-list. So: SUBSCRIBE sip:user@domain.com SIP/2.0 Event: presence.alert Accept: application/uri-list then the NOTIFY: NOTIFY sip:subscriber@school.edu SIP/2.0 Event: presence.alert Content-Type: application/uri-list http://school.edu/user/current-pres-doc.pl One might even have multipel URI there of several schemes, supporting a variety of pulls. -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 ------_=_NextPart_001_01C177D4.0A2BCFA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: Question regarding NOTIFY messages using = UDP.

Good idea (HTTP url)... The thought had occurred to = me briefly, but I really hadn't thought it out much.

Actually, would it be possible to simply throw a = request URI into a presence notification for any sort of a = transfer?

i.e. to get around problems with message length and = firewall/NAT issues, is it important that we actually include the = cpim-xpidf+xml document in the NOTIFY, or could we simply add that you = might get an application/cpim-xpidf-url document, that the client can = go grab using HTTP. Solves all of the problems in one tidy = package.

That way clients initiate the transfer of the = presence document, and can choose TCP if they wish (likely), or if they = suspect they're behind a firewall/NAT. When they make the subscription, = they could include an accept with the application/cpim-xpidf-url = content type which would simply be an HTTP or HTTPS url to where to = grab the presence document.

Another added advantage would be that you could use a = "cheap" transport like UDP to send the notification, and then = let the client initiate an "expensive" transport like TCP or = TLS, on demand, to go get the document when it needs to. That would = allow established secure HTTP transfers to take place when retrieving = the data that we're trying to pull.

We could stipulate that the document that the HTTP = url points to must be an application/cpim-xpidf+xml formatted = document.

Regards,

Brian Stucker
Nortel Networks



-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Monday, November 26, 2001 2:03 PM
To: 'Michael Hammer'; Jonathan Rosenberg
Cc: 'adam.roach@ericsson.com'; Stucker, Brian = [NGB:B635:EXCH]; simple;
Nava, Alex [NGC:B634:EXCH]; Sollee, Patrick = [NGC:B680:EXCH]; Sen, Sanjoy
[NGB:B692:EXCH]
Subject: RE: [Simple] RE: Question regarding NOTIFY = messages using UDP.




 

> -----Original Message-----
> From: Michael Hammer [mailto:mhammer@cisco.com]
> Sent: Wednesday, November 21, 2001 10:11 = AM
> To: Jonathan Rosenberg
> Cc: 'adam.roach@ericsson.com'; 'Brian Stucker'; = simple; Alex Nava;
> Patrick Sollee; Sanjoy Sen
> Subject: RE: [Simple] RE: Question regarding = NOTIFY messages
> using UDP.
>
>
> Jonathan,
>
> While not favoring any fragmentation mechanism = for SIP, does
> this preclude
> any implementation (higher level application = using SIP) from
> choosing to
> send the body of the Notifies as incremental = parts?  It would
> seem that the
> SIP-level mechanisms would be unaware of the = full nature of
> the body which
> it carries and should place no restrictions on = that body.
>
> That is, it provides no mechanism nor precludes = use of such a
> mechanism.

The spec assumes full-state, and talks about using = CSeq to determine the
most recent document, which wouldn't make sense for = partial documents as you
have described.

An extension could in principle override this, and = you could define a
document format that supports partial = information.

However, I still assert that:

1. this is a problem in theory only
2. if the docs do become large, delta encoding is = better

Honestly, the problem is more for other event = packages that may convey
larger amounts of state.


Brian later writes:
> Ok, here's a thought...
> If we're in a position where we think we're = going to need to use TCP (or
some other
> connection-oriented protocol) to notify the = watcher (in this example, a
presence
> subscriber), but it's difficult to keep up a = bunch of TCP connections, we
use the
> following general mechanism.
>
> 1. We send the watcher a NOTIFY that says in = effect "you need to fetch the
current state
> of this resource" (in this case, probably = using UDP).
>
> 2. The watcher responds to the NOTIFY with a = 200 OK however it chooses.
>
> 3. The watcher sends a SUBSCRIBE in to fetch = the current state of the
resource (in this
> case a presentity) using the transport of it's = choosing. If it knows it's
behind a
> firewall, or a NAT, then it can pick TCP, for = instance.

Actually, we've been toying with the idea of not even = using SUBSCRIBE for
this. An HTTP request is just fine for synchronously = fetching a document;
thats what its designed to do.

One could think of this as another sub-package, say = "alert". If you
subscribe to foo.alert, you get a NOTIFY when foo = changes, but the NOTIFY
contains a body type that is always short - = providing a URL for actually
retrieving the thing that has changed. In fact, the = default could be as
simple as application/uri-list. So:

SUBSCRIBE sip:user@domain.com SIP/2.0
Event: presence.alert
Accept: application/uri-list

then the NOTIFY:

NOTIFY sip:subscriber@school.edu SIP/2.0
Event: presence.alert
Content-Type: application/uri-list

http://school.edu/user/current-pres-doc.pl


One might even have multipel URI there of several = schemes, supporting a
variety of pulls.


-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

------_=_NextPart_001_01C177D4.0A2BCFA0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 28 13:09:20 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26365 for ; Wed, 28 Nov 2001 13:09:20 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fASI6s7x017304; Wed, 28 Nov 2001 13:06:57 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11688; Wed, 28 Nov 2001 13:08:12 -0500 (EST) Received: from zander.antihe.ro (dsl231-037-205.sea1.dsl.speakeasy.net [216.231.37.205]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with SMTP id NAA11677 for ; Wed, 28 Nov 2001 13:07:50 -0500 (EST) Received: (qmail 72863 invoked by uid 1002); 28 Nov 2001 18:07:26 -0000 From: Torrey Searle To: simple@mailman.dynamicsoft.com Message-ID: <20011128100726.A72830@antihe.ro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Subject: [Simple] Watcher Information 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, 28 Nov 2001 10:07:26 -0800 Would it be possible to add an attribute to the watcher info for expiration? It seems like being told how long a pending or active subscription could be usefull information. Torrey Searle _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 28 13:30:26 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27984 for ; Wed, 28 Nov 2001 13:30:26 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fASISL7x017490; Wed, 28 Nov 2001 13:28:21 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11784; Wed, 28 Nov 2001 13:30:10 -0500 (EST) 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 NAA11771 for ; Wed, 28 Nov 2001 13:29:43 -0500 (EST) 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 MAA10781 for ; Wed, 28 Nov 2001 12:29:14 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Wed, 28 Nov 2001 12:20:31 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 12:26:18 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0EF52F10@zrc2c012.us.nortel.com> From: "Brian Stucker" To: Torrey Searle , simple@mailman.dynamicsoft.com Subject: RE: [Simple] Watcher Information MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1783A.2C131950" 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, 28 Nov 2001 12:26:18 -0600 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_01C1783A.2C131950 Content-Type: text/plain; charset="iso-8859-1" Why can't the scheme in the -01 events draft be used? It gives you an overall expiration time and the client should already know it from the presence subscription messages. Brian -----Original Message----- From: Torrey Searle [mailto:tsearle@antihe.ro] Sent: Wednesday, November 28, 2001 12:07 PM To: simple@mailman.dynamicsoft.com Subject: [Simple] Watcher Information Would it be possible to add an attribute to the watcher info for expiration? It seems like being told how long a pending or active subscription could be usefull information. Torrey Searle _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple ------_=_NextPart_001_01C1783A.2C131950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] Watcher Information

Why can't the scheme in the -01 events draft be used? = It gives you an overall expiration time and the client should already = know it from the presence subscription messages.

Brian

-----Original Message-----
From: Torrey Searle [mailto:tsearle@antihe.ro]
Sent: Wednesday, November 28, 2001 12:07 PM
To: simple@mailman.dynamicsoft.com
Subject: [Simple] Watcher Information


Would it be possible to add an attribute to the = watcher info for expiration?  It seems like being told how long a = pending or active subscription could be usefull information.

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

------_=_NextPart_001_01C1783A.2C131950-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 28 16:51:54 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16062 for ; Wed, 28 Nov 2001 16:51:54 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fASLnN7x018963; Wed, 28 Nov 2001 16:49:23 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12430; Wed, 28 Nov 2001 16:51:10 -0500 (EST) 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 QAA12418 for ; Wed, 28 Nov 2001 16:50:06 -0500 (EST) 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 fASLmF7x018950; Wed, 28 Nov 2001 16:48:15 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 16:49:43 -0500 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F338E849@DYN-TX-EXCH-001.dynamicsoft.com> From: Robert Sparks To: "'simple@mailman.dynamicsoft.com'" Cc: "Jon' 'Peterson (E-mail)" , Jonathan Rosenberg MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] WGLC - watcherinfo 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, 28 Nov 2001 16:49:42 -0500 There's been very little response to the request for discussion on watcherinfo. Hopefully, that means the drafts are ready to go. This is the last call for comments on these drafts: draft-ietf-simple-winfo-package-00.txt draft-ietf-simple-winfo-format-00.txt This call will close on 12/21, but please have comments on technical deficiencies in by 12/7 so that we can discuss them at IETF 52. RjS _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Wed Nov 28 17:22:44 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18860 for ; Wed, 28 Nov 2001 17:22:43 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fASMKL7x019215; Wed, 28 Nov 2001 17:20:22 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12555; Wed, 28 Nov 2001 17:22:09 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12544 for ; Wed, 28 Nov 2001 17:21:22 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id fASMKuY26588 for ; Wed, 28 Nov 2001 16:20:56 -0600 (CST) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id fASMKu817800 for ; Wed, 28 Nov 2001 16:20:56 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Nov 28 16:20:54 2001 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 16:20:54 -0600 Message-ID: From: "Sean Olson (EUS)" To: "'Robert Sparks'" , "'simple@mailman.dynamicsoft.com'" Cc: "Jon' 'Peterson (E-mail)" , Jonathan Rosenberg Subject: RE: [Simple] WGLC - watcherinfo MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1785A.ECDC60E0" 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, 28 Nov 2001 16:20:45 -0600 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_01C1785A.ECDC60E0 Content-Type: text/plain; charset="iso-8859-1" Well, if you insist. I don't see the need for the "event" in the XML winfo format. The "status" seems to carry everything that is needed. The "first-subscribed" element also seems a bit odd. Either this requires the PA to maintain information that lasts longer than a subscription (a bad idea) or it is a mislabelled and probably useless piece of information. What is the purpose of providing (optionally) the "notify-address" in the winfo? /sean >-----Original Message----- >From: Robert Sparks [mailto:rsparks@dynamicsoft.com] >Sent: Wednesday, November 28, 2001 3:50 PM >To: 'simple@mailman.dynamicsoft.com' >Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg >Subject: [Simple] WGLC - watcherinfo > > >There's been very little response to the >request for discussion on watcherinfo. >Hopefully, that means the drafts are ready >to go. > >This is the last call for comments on these drafts: >draft-ietf-simple-winfo-package-00.txt >draft-ietf-simple-winfo-format-00.txt > >This call will close on 12/21, but please have >comments on technical deficiencies in by 12/7 >so that we can discuss them at IETF 52. > >RjS > >_______________________________________________ >simple mailing list >simple@mailman.dynamicsoft.com >http://mailman.dynamicsoft.com/mailman/listinfo/simple > ------_=_NextPart_001_01C1785A.ECDC60E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] WGLC - watcherinfo

Well, if you insist. I don't see the need for the = "event"
in the XML winfo format. The "status" = seems to carry
everything that is needed. The = "first-subscribed" element
also seems a bit odd. Either this requires the PA to =
maintain information that lasts longer than a = subscription
(a bad idea) or it is a mislabelled and probably = useless
piece of information. What is the purpose of = providing
(optionally) the "notify-address" in the = winfo?

/sean

>-----Original Message-----
>From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
>Sent: Wednesday, November 28, 2001 3:50 = PM
>To: 'simple@mailman.dynamicsoft.com'
>Cc: Jon' 'Peterson (E-mail); Jonathan = Rosenberg
>Subject: [Simple] WGLC - watcherinfo
>
>
>There's been very little response to the
>request for discussion on watcherinfo.
>Hopefully, that means the drafts are = ready
>to go.
>
>This is the last call for comments on these = drafts:
>draft-ietf-simple-winfo-package-00.txt
>draft-ietf-simple-winfo-format-00.txt
>
>This call will close on 12/21, but please have =
>comments on technical deficiencies in by 12/7 =
>so that we can discuss them at IETF 52.
>
>RjS
>
>_______________________________________________
>simple mailing list
>simple@mailman.dynamicsoft.com
>http://mailman.dynamicsoft.com/mailman/listinfo/simple=
>

------_=_NextPart_001_01C1785A.ECDC60E0-- _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Thu Nov 29 15:07:47 2001 Received: from mail1.dynamicsoft.com ([63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07645 for ; Thu, 29 Nov 2001 15:07:46 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fATK3R7x024447; Thu, 29 Nov 2001 15:03:28 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16533; Thu, 29 Nov 2001 15:05:12 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16516 for ; Thu, 29 Nov 2001 15:04:34 -0500 (EST) Received: from cannon.cisco.com (cannon.cisco.com [161.44.228.16]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fATK46E25557; Thu, 29 Nov 2001 15:04:08 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAE28829 (AUTH pkyzivat); Thu, 29 Nov 2001 15:05:25 -0500 (EST) Message-ID: <3C0693F1.7AA8E623@cisco.com> From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "'sip@ietf.org'" , Ben Campbell , simple@mailman.dynamicsoft.com Subject: Re: [Simple] New I-D on IM transport References: Content-Type: text/plain; charset=us-ascii 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: Thu, 29 Nov 2001 15:00:49 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > - what if there is no problem with signalling but there is a problem > > with the media stream? Then the reinvite will reach the original > > endpoint rather than a backup. It will not be able to distinguish this > > reinvite from one for some other purpose, like session timer > > refresh. It > > will note that the sdp has not changed, and may choose to > > simply return > > the last sdp it sent. (This could happen if the sip and media > > travel on > > different network connections to the same host, or if the > > media is on a > > separate device with its own network connection.) > > I guess this seems to me to be the right behavior. What would you want to > happen in this case? Doing nothing in response to the problem seems wrong to me. But clearly it is difficult to figure out the right thing to do. Possible actions: - switch to a different port. See if that helps. - switch to a different media server, if it is independent of the sip UA itself - record the fact that a caller reinvited because of presumed media problems at this end. Eventually an accumulation of these might lead to taking this box out of service. Some or all of these responses could be tried *if* the called system knew the reinvite was sent because of problems with the call. > > - in a separate mail thread on the comedia draft, we identified some > > added problems with reinvites and connection oriented media. In that > > case, what is negotiated in the sdp is used to establish a media > > connection, so it isn't idempotent to subsequent invitations. There is > > need to indicate in the sdp whether to renegotiate the connection or > > not. I don't think we ever fully resolved that. But I believe it is > > important that something in the sdp be changed to indicate a desire to > > renegotiate the connection. The same kind of scenario applies here. > > This is a good point. I think its a pure co-media issue, though, and that > needs to be addressed in that draft. Fair enough, as long as the rules you are trying to craft dovetail with that. It may not be sufficient to simply reinvite with same old SDP; it may be required to do something slightly different on a per-media basis. > > All of these issues suggest to me that some explicit information needs > > to be conveyed indicating what is being attempted. Part of > > this might be > > a Reason header indicating that the reinvite is being sent to recover > > from a perceived problem. > > I'm still not convinced, so long as the comedia issue is handled. You may be right, but I have the feeling the problem is bigger than just comedia. Reinvites can be sent for many reasons, and errors can show their symptoms in many ways. The assumption you are making is that the reinvite will always induce another problem, and that the resolution of that problem will fix the original one. Paul _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple From simple-admin@mailman.dynamicsoft.com Fri Nov 30 04:20:30 2001 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00189 for ; Fri, 30 Nov 2001 04:20:29 -0500 (EST) Received: from mailman.dynamicsoft.com ([192.168.4.50]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fAU9HK7x027060; Fri, 30 Nov 2001 04:17:20 -0500 (EST) Received: from mailman.dynamicsoft.com (localhost [127.0.0.1]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18921; Fri, 30 Nov 2001 04:19:10 -0500 (EST) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by mailman.dynamicsoft.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18910 for ; Fri, 30 Nov 2001 04:18:11 -0500 (EST) Received: from libero.it (193.70.192.44) by smtp1.libero.it (6.0.032) id 3BF1798A0058E995; Fri, 30 Nov 2001 10:17:33 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q??=" To: jdrosen@dynamicsoft.com Cc: simple@mailman.dynamicsoft.com X-XaM3-API-Version: 2.5 X-type: 0 X-SenderIP: 193.205.164.113 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mailman.dynamicsoft.com id EAA18910 Subject: [Simple] =?iso-8859-1?Q?Event_header_in_the_Register_request?= 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, 30 Nov 2001 10:17:33 +0100 Content-Transfer-Encoding: 8bit Hi all, In the Scenario "Presence Server with Client notifications",there isn't an Event header in the Register Request. I suppose isn't necessary because will be the client to inform the watcher if he support(in which case he send a 200 OK)or not(in which case he send a 489)a particular event,like Presence for example. In the Scenario "Presence Server with Server notifications",in the registration phase,i think its mandatory including an Event header, otherwise it is impossible for the server to understand if the registration is for Presence,for example, or other event. salvatore loreto loreto@coritel.it www.coritel.it _______________________________________________ simple mailing list simple@mailman.dynamicsoft.com http://mailman.dynamicsoft.com/mailman/listinfo/simple